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© System for integrating application programs in a heterogeneous network enviroment 

© A system which integrates applications that run on a plurality of homogenous or heterogeneous computers 
on a network. System Configuration files (510) in source code are created from a high levei definition of the 
distributed system (LAN) which is to be integrated. The configuration files (510) include data such as the types 
and formats of data for each process (402) on each node (400) of the system, identification of all applications 
and machine types, topography and the data manipulations needed for sending messages and files and the like 
from an application program in a first computer language and of a first data type to an application program in a 
second computer language and of a second data type. Node-specific data manipulation modules (DMM 528) are 
formed at each node (400) during startup of the system, and these modules are automatically distributed to 
nodes (400) on the network having the same architecture. The invention allows applications having different 
physical data characteristics to communicate by using the data manipulation modules (DMM 528) so formed to 
manipulate the data at the source program into a common data representation (CDR) having data types common 
to all of the languages represented by the system and then reconverting the data to the local representation at 
the destination node. 
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BACKGROUND OF THE INVENTION 
Field of the Invention 

s The present invention relates to a system for integrating existing application programs in a networked 

environment, and more particularly, to a system with mechanisms for transforming and manipulating data 
messages for transfer between different applications on the same computer or on different computers 
connected via a network or networks and having the same or different computer architectures. 

10 Descr *P tion of the Prior Art 

Since the beginning of the computer age, computers and, in particular, computer software programs 
have been used in a variety of settings to automate processes which were previously conducted 
mechanically. This automation has typically led to improved efficiency and increased productivity. However, 

75 because of the costs of such automation, automation of large businesses and factories has often been 
conducted on a piecemeal basis. For example, different portions of an assembly line have been automated 
at different times and often with different computer equipment as a result of the varying functionalities of the 
various computer systems available at the time of purchase. As a result, many assembly lines and 
businesses have developed "islands of automation" in which different functions in the overall process are 

20 automated but do not necessarily communicate with one another. In addition, in the office environment 
LANs have been used to allow new computer equipment to communicate; however, software applications 
typically may not be integrated because of data incompatibilities. 

Such heterogeneous systems pose a significant problem to the further efficiencies of automation since 
these different "islands of automation" and machines with incompatible data types connected to the same 

25 network cannot communicate with one another very easily. As a result, it has been difficult and expensive to 
control an entire assembly line process for a large manufacturing facility from a central location except on a 
piecemeal basis unless the entire factory was automated at the same time with homogeneous equipment 
which can intercommunicate. Thus, for those businesses and factories which have already been automated^ 
on a piecemeal basis, they are faced with the choices of eliminating all equipment so that homogeneous' 

30 equipment may be substituted therefor (with the associated prohibitive costs) or waiting for the existing 1 
system to become obsolete so that it can be replaced (again at significant expense). 

One solution to the above problem has been to hire software programmers to prepare custom code 
which allows the different "islands of automation" to communicate with each other. However, such an 
approach is also quite expensive and is rather inflexible and assumes that the overall system remains static. 

35 In other words, when further equipment and application software must be integrated into the overall system, 
the software programmers must be called back in to rewrite the code for all applications involved and to 
prepare additional custom code for interface purposes. A more flexible and less expensive solution is 
needed. 

The integration of existing heterogeneous applications is a problem which has yet to be adequately 

40 solved. There are numerous major problems in such integration of existing applications because of the 
differences in hardware and their associated operating systems and because of the differences in the 
applications themselves. For example, because computers are built on proprietary hardware architectures 
and operating systems, data from applications runn: ig on one system is often not usable on another 
system. Also, programmers must frequently change application code to create interfaces to different sets of 

45 network services because of the diversity of such network services. In addition, different applications use 
different data types according to their specific needs, and, as a result, programmers must alter a receiving 
application's code to convert the data from another application into types that the receiving application can 
use. Moreover, incompatible data structures often result because of the different groupings of data elements 
by the applications. For example, an element with a common logical definition in two applications may still 

so be stored in two different physical ways (i.e., application A may store it in one two-dimensional array and 
application B may store it in two one-dimensional arrays). Moreover, applications written in different 
languages usually cannot communicate with one another since data values are often interpreted differently. 
For example, C and FORTRAN interpret logical or boolean values differently. 

Partial solutions to the above problems have been proposed to provide distributed networks for allowing 

55 various applications to share data. In doing so, these applications have relied on transparent data sharing 
mechanisms such as Sun Microsystems 1 Network File System (NFS), AT&T's Remote File Sharing (RFS), 
FTAM (as defined by the MAP/TOP specifications), or Apollo's Domain File System. However, these 
systems are limited in that they allow data sharing but do not allow true integration of the different 
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application programs to be accomplished. 

Another example of a system for providing interprocess communication between different computer 
processes connected over a distributed network is the Process Activation and Message Support (PAMS) 
system from Digital Equipment Corp. This system generally allows processes to communicate with each 

5 other regardless of where the processes reside on a common network. Such processes may be located on 
a single CPU or spread across workstations, clusters, or local or wide area networks (LANs or WANs). The 
PAMs system manages all connections over the network and provides integration features so that 
processes on respective workstations, clusters and the like may communicate. In particular, the PAMs 
message processing system is a network layer which is implemented above other networks to transparently 

io integrate new networks and events into a common message bus. Such a system enables network 
configuration to be monitored and message flow on the message bus to be monitored from a single point. 
The result is a common programming interface for ail host environments to which the computer system is 
connected. Thus, all host environments appear the same to the user. 

For example, an ULTRIX host environment running ULTRIX-PAMS is directly connected to a VMS host 

rs running VAX-PAMS on its networks, and ULTRIX-PAMS uses VAX transport processes to route all 
messages over the network. Specific rules are then provided for routing messages using ULTRIX-PAMS 
and VAX transport processes, where the ULTRIX-PAMS functions as a slave transport in that it can only 
communicate to other PAMS processes via the network to a full function PAMS router. As a result, the 
PAMS system is limited in that there is no support for "direct" task-to-task communications between 

20 ULTRIX processes. In addition, since all traffic must be routed through a VAX-PAMS routing node, a single 
point of failure exists for the system. 

Other systems have been proposed for an information processing environment in which various 
machines behave as one single integrated information system. However, to date such systems are limited 
to connecting various subroutines of homogeneous applications running on different machines connected to 

25 a common network. For example, the Network Computing System (NCS) of Apollo is a Remote Procedure 
Call (RPC) software package which allows a process (user application) to make procedure calls to the 
services exported by a remote server process. However, such RPC systems are typically not fit for the 
development of a networked transaction management system, for NCS does not provide a message and file 
handling system, a data manipulation system, a local and remote process control system and the like which 

30 allows for the integration of existing applications. Rather, NCS allows for the building of new distributed 
applications, and does not provide for the integration of existing heterogeneous applications. RPCs instead 
isolate the user from networking details and machine architectures while allowing the application developer 
to define structured interfaces to services provided across the existing network. 

RPCs can be used at different levels, for the RPC model does not dictate how they should be used. 

35 Generally, a developer can select subroutines of a single application and run them on remote machines 
without changing the application or subroutine code. The simplest use of RPCs is to provide intrinsic access 
to distributed resources which are directly callable by an application, such as printers, plotters, tape drives 
for backup tasks, math processors for complex and time-consuming applications, and the like. A more 
efficient use of RPC at the application level would be to partition the application so that the software 

40 modules are co-located with the resources that they use. For example, an application which needs to 
extract data from a database could be partitioned so that the modules which access the database could 
reside on the database machine. 

A diagram of NCS is shown in FIG. 1. The system 100 therein shown generally consists of three 
components: an RPC run time environment 132, 134 which handles packaging, transmission and reception 

45 of data and error correction between the user and server processes; a Network Interface Definition Compiler 
(NIDC) 136 which compiles high-level Network Interface Definition Language (NIDL) into a C-language code 
that runs on both sides of the connection (the user and server computers); and a Location Broker 128 which 
lets applications determine at run time which remote computers on the network can provide the required 
services to the user computer. In particular, as shown in FIG. 1, a user application 102 interfaces with a 

so procedure call translator stub 104 which masquerades as the desired subroutine on the remote computer. 
During operation, the RPC run time system 106 of the user's computer and the RPC run time system 108 
of the server system communicate with each other over a standard network to allow the remote procedure 
call. Stub 110 on the server side, which masquerades as the application for the remote subroutine 112, then 
connects the remote subroutine 112 across the network to the user's system. 

55 The NCS system functions by allowing a programmer to use a subroutine call to define the number and 
type of data to be used and returned by the remote subroutine. More particularly, NCS allows the 
application developer to provide an interface definition 114 with a language called the Network Interface 
Definition Language (NIDL) which is then passed through NIDL compiler 116 to automatically generate C 
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source code for both the user and server stubs. In other words, the NIDL compiler 116 generates stub 
source code 118 and 120 which is then compiled with RPC run time source code 122 by C compilers 124 
and 126 and linked with the application 102 and user-side stub 104 to run on the user's machine while the 
subroutine 112 and its server-side stub 110 are compiled and linked on the server machine. After the 

5 application 102 has been written and distributed throughout the network, location broker 128 containing 
network information 130 may then be used to allow the user to ask whether the required services (RPC) are 
available on the server system. 

Thus, with NCS, the NIDL compiler automatically generates the stubs that create and interpret data 
passed between an application and remote subroutines. As a result, the remote subroutine call appears as 

70 nothing more than a local subroutine call that just happens to execute on a remote host and no protocol 
manipulations need to be performed by the application developer, in other words, the NCS system is 
primarily a remote execution service and does not need to manipulate data for transfer by restructuring a 
message to allow for conversion from one data type to another. A more detailed description of the NCS 
system can be found in the article by H. Johnson entitled "Each Piece In Its Place." Unix Review , June 

75 1987, pages 66-75, 

The RPC system of the NCS primarily provides a remote execution service which operates synchro- 
nously in a client/server relationship in which the client and server have agreed in advance on what the 
requests and replies will be. Applications must be developed specifically to run on NCS or substantially 
recoded to run on NCS. Moreover, because a remote procedure cannot tell when it will be invoked again t it 

20 always initiates communications at the beginning of its execution and terminates communications at the 
end. The initiation and termination at every invocation makes it very costly in performance for a remote 
procedure to set up a connection with its caller. As a result, most RPC systems are connectionless. This is 
why RPC systems such as NCS must build another protocol on top of the existing protocol to ensure 
reliability. This overhead causes additional processing to be performed which detracts from performance. 

25 Accordingly, although NCS provides a consistent method for remote execution in a heterogeneous 
network environment, it is designed primarily to broker distributable services such as printing and plotting 
across the network, where the user may not care which printer prints the information as long as it gets 
printed. Another type of service might be providing processing time for applications where a small amount 
of data in a message can trigger an intensive and time consuming calculation effort to achieve an answer^ 

30 that can itself be turned into a message. However, the NCS system cannot provide a truly integrated 
system for incompatible node type formats and data processing languages. 

None of the known prior art systems address the substantial problems of integrating existing heteroge- 
neous application in a heterogeneous and/or homogeneous network environment. Accordingly, there is a 
long-felt need in the art for an integration system which provides for flexible data transfer and transformation 

35 and manipulation of data among existing applications programmed in a networked environment of heteroge- 
neous and/or homogeneous computers in a manner that is transparent to the user. The present invention 
has been designed to meet these needs. 

SUMMARY OF THE INVENTION 

40 

The inventors of the subject matter disclosed and claimed herein have satisfied the above-mentioned 
long-felt needs in the art by developing a software tool which enables a system integrator or end-user 
flexibly and efficiently to produce run time software for integration of existing applications in a networked 
environment of heterogeneous computers. In order to achieve this goal, the present invention provides 

45 functionality equivalent to that of a combination of a message and file handling system, a data manipulation 
system, and a local and remote program control system. From the system integrator's viewpoint, the 
present invention provides a message handling system which allows data types and data formats to be 
different at each end of the messaging system, while any changes in data elements, data types or data 
formats of the messages will only require a reconfiguration of the system before start-up. Since reconfigura- 

50 tion is an administrative level activity, the user will not be required to change his or her source code in the 
communicating applications. 

Accordingly, the present invention is specialized for easy modification of data types and data formats 
passed so as to allow transparent communication between data processes of different formats on machines 
of different types. As a result, the application programs which are communicating need not be written in the 

55 same language or be downloaded onto the same computer type. The present invention further allows users 
to link existing applications with minimal or no changes to the code of the applications, thereby reducing the 
amount of custom code that needs to be written, maintained and supported for integrating existing systems. 
The present invention addresses the major integration problems noted in the background portion of this 
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specification by providing for local and remote inter-application data transfer whereby existing applications 
may be linked with minimal or no modifications to the applications. Synchronous and asynchronous 
memory-based message transfers and file transfers between applications are also supported. In addition, 
language, data format and data type differences are resolved utilizing data manipulation features such as 

s rearranging, adding or deleting fields and converting between data types in accordance with differences in 
hardware, language alignment, and data size. This is accomplished in a preferred embodiment by using a 
Common Data Representation (CDR) for the messages to be transferred between heterogenous nodes. 

The data manipulator (DMM) of the invention provides automatic manipulation of data during run time 
so that two communicating processes can use each others data without having to change their own data 

70 models. The data manipulator of the invention takes care of hardware discrepancies, application depen- 
dencies and computer language semantic differences. It can convert one data type to another, restructure a 
message format and assign values to data items. 

Typically, conversion routines are only good for the two machine architectures and/or two languages 
involved. With the addition of any new language or machine architecture to this networked system, a new 

75 set of routines must be created on all previous machine architectures in the network to support the transfer 
of the data to applications on the new machine or to applications written in the new language. The present 
invention has been designed to minimize the alteration or addition of routines that were written on older 
machine architectures in the network when new machines or languages are added to the system. Also, by 
making the data manipulation module node-specific, it is also possible in accordance with the invention to 

20 cut down on the number of sets of routines a particular machine might need to send/receive data to/from 
other machines. 

BRIEF DESCRIPTION OF THE DRAWINGS 



25 The objects and advantages of the invention will become more apparent and more readily appreciated 
from the following detailed description of presently preferred exemplary embodiments of the invention taken 
in conjunction with the accompanying drawings of which: 

FIG. 1 schematically illustrates a prior art Network Computing System (NCS) which allows applications 
running in a distributed environment to share computations as well as data; 
30 FIG. 2 schematically illustrates the basic components of the integration system in accordance with the 
invention; 

FIG. 3 schematically illustrates how the invention can be used to connect an application to others on the 
same system or to applications that reside on one or more remote systems. 

FIG. 4 schematically illustrates the configuration of the run time components of the integration system in 
35 accordance with the invention; 

FIG. 5 schematically illustrates the creation of a Data Manipulation Module (DMM) of the invention 
through start-up by the start-up node; 

FIG. 6 schematically illustrates the distribution of the configuration information from the compilation node 
to each of the respective nodes of the same computer architecture as the compilation node; 
40 FIG. 7 is a flowchart illustrating the procedure for start-up of the integrated system which uses this 
invention; 

FIG. 8 schematically illustrates an example of a heterogeneous networking system in accordance with 
the invention; and 

FIG. 9 illustrates sample configuration files for the sample configuration shown in FIG. 8. 

45 

DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EMBODIMENT 

A system with the above-mentioned beneficial features in accordance with a presently preferred 
exemplary embodiment of the invention will be described below with reference to FIGS. 2-9. It will be 

so appreciated by those of ordinary skill in the art that the description given herein with respect to those 
figures is for exemplary purposes only and is not intended in any way to limit the scope of the invention. All 
questions regarding the scope of the invention may be resolved by referring to the appended claims. 

As noted above, present day manufacturing computer systems have often been built from the bottom 
up, thereby resulting in the creation of isolated "islands of automation." For example, the areas of design 

55 and engineering, manufacturing resource planning, and manufacturing have typically been independently 
automated. As a result, these islands of automation consist of heterogeneous computer systems, operating 
systems, and data base systems. However, manufacturers are now looking for higher levels of efficiency 
and productivity than is available in such prior art systems. Computer Integrated Manufacturing (CIM), the 
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integration of these islands of automation, is a means of achieving such higher levels of efficiency and 
productivity. The preferred embodiment of the present invention is designed for facilitating the development 
of CIM solutions. As will be clear from the following, this is accomplished by integrating existing application 
programs in a networked environment of heterogeneous computers by providing flexible data transfer, 

5 transformation and manipulation mechanisms. 

Generally, the present invention produces run time code that comprises several active programs (or 
software modules) which are used at run time to provide communication between applications on the same 
or different nodes, where a node is any computer in the network's domain. The applications can be on 
different computer systems or on the same computer and may be in the same or different computer 

w languages. These run time programs handle the data transfer from the source application program to the 
destination application program by transforming the data from the source program into an architectural and 
language independent format using a CDR. For example, the field and record data in the source machine's 
format is converted to the destination machine's format by first converting to a CDR using locally stored 
routines which convert the internal representation of data on the source machine to the common data 

is representation format, and after the transfer of the CDR data, the CDR data is converted to the internal 
representation for data on the destination machine using locally stored routines. In particular, predefined 
links of sources and destinations are cailed by software modules of the invention to make certain that the 
information is correctly routed from the source to the destination machine. This latter information is called 
the configuration data and corresponds to information provided by the system's integrator concerning the 

20 nodes, processes and possible data manipulations to be performed on the network. 

The system of the invention generally consists of run time and non-run time components. The run time 
components of the invention will be described in more detail with respect to FIGS. 2-4, while the non-run 
time components will be described in more detail below with respect to FIGS. 5 and 6. 

As shown in FIG. 2, the run time components 208 include a data manipulator/translator, a data 

25 transporter, configuration tables and a system manager. As will be described in more detail below, the data 
manipulator/translator functions to transform data to and from a CDR format acceptable to a given process 
of a specified host computer, while the data transporter functions to pass data in the common data 
representation to/from the network system for sending to a destination application. However, as will be 1 
noted below, the data transporter also functions to send unmanipulated data to the destination application 

30 when the source and destination applications have the same type and format and hence the message data 
does not need to be manipulated. 

Thus, as shown in FIG. 2, in the system of the invention a plurality of user application programs 202 are 
connected via application adaptors 204 using access routines 206 so as to communicate with the run time 
components 208 of the invention. The application adaptors 204 comprise user-written programs which act 

as as software bridges between the user's application and the system of the invention. In particular, these 
user-written application adaptor programs call access routines from an access routine library 206 in order to 
send messages, copy files, control processes, and the like on the network of the invention. These access 
routines 206 are thus used to provide the user with the necessary commands for preparing the application 
adaptor programs. Sample access routines are provided below as an Appendix A hereto, and sample 

40 adaptors are attached as an Appendix B hereto. 

System manager 210 enables a user to administer operation of the system during run time operation. 
For example, the system manager 210 allows the user to access the software of the invention to validate 
configuration, start-up and shut-down the system and perform other system management functions. The 
command processor 212, on the other hand, corresponds to a module accessed through the system 

45 manager 210 so as to allow a user to interactively test the messages and links to any process or node 
within the domain of the invention. (As used herein "domain" means the collection of computers that are 
configured to work together in accordance with the invention.) In addition, configuration files 214 contain 
information about the nodes, the structure of the data produced and consumed by the processes, the 
manipulations that must be performed on data produced by an application so that it is acceptable by 

so different processes, and the links binding manipulations to specific languages. Such information is provided 
by the systems integrator before run time and will be discussed in more detail below. The run time 
components are loaded into each node at start-up time using the system manager 210, and these 
components manipulate messages (as necessary) and transport them using the data transporter. The 
manipulations are performed in accordance with data in configuration files 214 held in memory at each 

55 node. Finally, the data transporter communicates with the network services 216 to pass the message to the 
destination node. 

FIG. 3 shows a system in accordance with the invention where two nodes on a LAN have run time 
integration systems A and B in accordance with the invention for integrating applications 1-4. As shown, 

6 
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each node is loaded with the run time system of the invention (including all elements shown in FIG. 2) for 
allowing the processes 1-4 to communicate even if they have different data types and language formats. In 
FIG. 3, there are various possibilities for communication between the processes shown. For example, 
Application 1 may communicate with Application 2 through the integration System A. Application 1 naay 

s generate data meant for Application 2 in the shared memory of the host computer or in the form of files 
resident on the host disk. This data is picked up by Application Adaptor 1 and passed to Integration System 
A, which then gives it to Application Adaptor 2 for passing on to Application 2. Integration System A 
optionally can be instructed to manipulate the data before sending it to Application 2. The data manipulation 
can consist of literal assignments to data, moving data from one structure to another, and translating data 

10 from one structure to another. 

On the other hand, the data may be picked up by Application Adaptor 1 and given to Integration 
System A. This data is then sent across the LAN to Integration System B. Application Adaptor 3 is given the 
data by Integration System B which then passes it Application 3 for its use. The user can decide whether 
any necessary data manipulations are done by Integration System A or Integration System B. 

75 FIG. 4 shows an implementation of the present invention on a given node 400 of a heterogeneous 
network system during run time. As shown, the integration system of the invention integrates all of the 
user's application programs (processes) 402 which run on the node 400. Applications running on other 
nodes (not shown) are similarly integrated- As noted above with respect to FIG. 2, these application 
programs 402 are respectively given access to the integration system of the invention via access routines 

20 404, which communicate with the integration system of the invention via a library of access routines such as 
those in Appendix A. 

The request manager (RM) 406 maintains a single queue for all user's application program requests so 
that one entry per defined process on node 400 may be read at a given time. The request manager 406 
reads the request from the application program 402 and performs the requested action. Requests can be of 
25 the following types: reading a message, sending a message, sending a file, starting another process, 
stopping another process, clearing the RM message queue area, recording an error on spooling device 410, 
setting the options for data transfer, deleting a particular message and the like, as apparent from the sample 
I access routines in Appendix A. For example, a user's application program 402 may call an access routine 

, f to send a message to an application program on another node to indicate that a value monitored by the 

* 30 application program 402 has changed state. The request manager 406 will then check its configuration 

tables 408 and the request from the application adaptor to see if a data manipulation was requested and is 
necessary for the sending of the message to the remote node. As will be described below with respect to 
FIG. 5, the configuration tables 408 will contain information about all nodes, processes and data manipula- 
tions possible for all message transfers within the network. Accordingly, by determining the source process 
35 and the destination process of the message request as well as the respective nodes and whether the 
message requested specified a link logical name, the request manager 406 can determine whether the data 
needs to be manipulated for the transfer. The request manager 406 also maintains a message queue 
(memory area) 409 which contains linked lists of data messages for incoming data from other processes. In 
addition, request manager 406 may log user messages to disc 410, if requested, by the sending process. 
40 Information such as error messages and the like also may be stored for use during system diagnostics. 

When request manager 406 determines that an indicated message needs to be manipulated (i.e., the 
source message needs to be converted to a different format and/or different language), the request is 
passed to data manipulation module (DMM) 412 where the message is converted to a common data 
representation (CDR) as will be described below before being sent to the destination node. If the message 
45 from the application program 402 calls for a transfer of a data file, .the indicated file is transferred by File 
Transfer Module (FTM) 414 to the destination node. A file message containing file information is sent to 
ONM 416 after a successful file transfer. If the request manager 406 determines that the application 
program is to send a message to a destination process without manipulation, no manipulation is performed. 
The message data is thus sent directly to Outgoing Network Manager (ONM) 416. ONM 416 receives the 
so unmanipulated message from request manager 406. a message from the File Transfer Module 414 
indicating that a file has been transferred or the message converted to its common data representation by 
data manipulation module 412 and outputs the message onto the LAN by making a network service call to 
send the message to the destination node. Messages that are specified as "critical" by the sending process 
and which cannot be successfully sent over the network to the destination node are stored (spooled) by 
55 ONM 416 to disc file 420. Failure to send a message can occur for several reasons including a node or 
network failure or a system shutdown. ONM re-attempts to send a message previously spooled to disc 420 
when the original cause of the failure to send the message has been corrected. 

If the sending process specifies that a message is to be sent "with-wait", then ONM 416 sends status 
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information to request manager 406's input queue when the message could not be sent to the destination 
node. However, if a message doqs not have to be manipulated and the destination process resides on the 
same node, then the message is not sent via ONM 416. Instead, the message is placed directly into the 
destination process* message area queue, preventing unnecessary data transmission. If the sending 

5 process specifies that a message is to be sent with "guaranteed delivery then the request manager 406 
wilt save those received messages in disc file 410 and will delete such messages only if there is a deletion 
request from an application program 402. A read request is typically done by a receiving process before a 
deletion request is done. If a message is not to be sent with guaranteed delivery, then request manager 406 
saves the message in its memory area 409 and the message is available to the receiving process via a read 

to message request. When the receiving process does a read request it can specify whether the message is 
to be deleted or not. 

Incoming network manager (INM) 418 receives incoming messages from the network and determines 
whether these messages need to be converted to local format from the common data representation format 
before being sent to the destination application program 402. If such a translation is necessary, as when the 
75 source node was of a different data type or the source programming language was different, the message is 
converted from the common data representation to the local data representation using a library of 
conversion (unmarshailing) routines before the message is sent to the input queue of request manager 406. 
Incoming messages which do not require such manipulation are sent directly to the input queue of the 
request manager 406. 

20 Finally, as noted above with respect to FIG. 2, a system manager 422 is also preferably provided to 
allow the user to administer the system management functions of the integration system of the invention 
during run time. Preferably, a particular node is selected for this purpose. 

The manipulations must take place when an application A having a first language A and data fields of a 
first type is to communicate during run time with an application B having a second language B and data 

25 fields of a second type. In accordance with the manipulation technique of the invention, a Data Definition 
Language (DDL) is used to define the data fields of the application program A and the application program 
B. The data fields of the DDL are then manipulated (rearranged) or the data types are converted by a Data 
Manipulation Language (DML) to that of a Common Data Representation (CDR) having a universal encoding! 
scheme such as Abstract Syntax Notation One's (ASN.1) Basic Encoding Rules (BER). The manipulated I 

3Q data is then converted at the destination node into language B with associated data fields for application B. 
DDL and DML will now be described in more detail. 

The aforementioned Data Definition Language (DDL) is a high level language used in accordance with 
the invention to define the logical structure and types of data used by all application programs on the 
network. More particularly, DDL is used to define data types with declarations in the Data Definition 

35 configuration file (Ddef) as will be described in more detail below with respect to FIG. 5. Traditional 
languages such as C, FORTRAN, and PASCAL are directly tied to the machine architecture in which they 
are implemented. This is because while different languages may have identical logical data types, those 
data types may be physically represented differently. For example, both C and FORTRAN have multi- 
dimensional array types; however, to store this data type, C uses row-major ordering while FORTRAN uses 

40 column-major ordering. DDL provides a full set of predefined data types that lets the system integrator 
describe the logical layout of the data used in application programs. In addition to the basic data types in 
most languages, DDL may include an additional data type called "opaque" in accordance with the invention, 
where "opaque" is a custom data type used to describe "type-less" data. 

Data in DDL is defined in a manner roughly equivalent to the type definition in C or the type declaration 

45 in Pascal. DDL declarations in accordance with the invention are similar to the data declarations sections of 
standard languages such as C and PASCAL and hence are believed to be well within the level of skill of 
one of ordinary skill in the art. For example, the DDL of the invention preferably includes information about 
the data types of all the procedures, and unlike the prior art, the DDL of the present invention allows for 
conversion from one data type to another in accordance with the DML described in more detail below. 

so Moreover, unlike traditional languages, a DDL definition in accordance with the invention does not bind any 
particular language or machine representation to the data definition. Rather, data definitions and machines 
are linked through a linkage definition as will be described below. Thus, the DDL in accordance with the 
invention is primarily concerned with the logical layout of data, and accordingly, a suitable DDL which 
supports the languages on the network to be integrated is believed to be well within the skill of one of 

55 ordinary skill in the art. By way of example, a partial description of a possible DDL supporting C, FORTRAN 
and Pascal on a network is described in Appendix C. Appendix C aiso includes BNF syntax diagrams for 
DDL declarations in such a case. 

Data Manipulation Language (DML) as used herein is a high-level language that is used to manipulate 
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data. After the data types are defined in DDL (in Ddef), the manipulations that must be performed on that 
data are defined in the Data manipulation definition configuration file (Dman) using DML as will be described 
below with respect to FIG. 5. The data manipulation declarations can be either assignment statements or 
move statements. Assignment statements set default values for destination structures, while move state- 

s ments move the source data structure to the destination data structure, correcting for differences in 
languages and machine architectures, and providing type conversions where necessary. These type 
conversions may be performed on boolean, integer, floating point and ASCII fields. 

As an example of a DML in accordance with the invention, a DML is described in Appendix D for a 
network have a DDL supporting C, FORTRAN and Pascal. Appendix D also includes BNF Syntax diagrams 

/o for DML definitions in such a case. One skilled in the art will appreciate that the DML described in Appendix 
D is for a specific embodiment and may be readily modified by one skilled in the art in accordance with the 
general principles set forth herein. 

SETUP PROCEDURES 

75 

FIGS. 5-7 illustrate the procedure for starting the system and setting up the DMM run time module 
described above with respect to FIG. 4. However, before describing these figures, the basic steps in the 
task of integration analysis that a system integrator or end user would follow in accordance with the system 
of the invention wilf be described. During the process, the system integrator completes a high level design 

20 of the integration system of the invention by determining the number and general functions of the processes 
needed to fulfill defined functional requirements. This information is required in both configuring the system 
and developing the application adaptors for it. 

Basically, configuring the system of the invention consists of creating with any text editor a set of 
configuration files that describes the data to be transported and the operating environment. The configura- 

25 tion files provide information about the data such as the way it is structured, how to access it, how to 
manipulate it. and how to display it. They describe the operating environment by defining the computers in 
the network, their links, and the types of processes. The configuration fields are formed by the system 
integrator or end user in accordance with the following steps. 

30 1 . The Functional Requirements Analysis. 

Functional requirements analysis means clearly defining the environment in which integration by the 
invention is to be performed so that' the systems integrator can do a high-level design of the system to be 
integrated. In other words, the user determines what is to be accomplished by integration so that the 

35 requirements of such integration can be specified in a programmatic interface development phase. For 
example, the user may want several applications that manage part of a manufacturing system, such as 
tracking and scheduling work orders, to be able to communicate and exchange data. The user will need to 
know the resources, namely, the applications that perform particular functions or processes, the machine 
nodes on which those applications reside (i.e., logical node name, machine type, physical node name, and 

40 so forth), and network characteristics. Such network information is stored in a network definition (Netw) 
configuration file. 

2. Data Flow and Application Analysis 

45 The user must also analyze the types of data and the movement of the data between the applications 
that will be integrated. The user also will need to identify any synchronization needed to control the flow of 
data or to insure that the data remains consistent. Whether the data flows between different applications on 
the same system or between applications on different systems, the user also must know the specifics of the 
data being moved between applications. For example, the user must know the structure of messages and 

so source applications sent and what format the destination application will accept. The user must also know 
the programming language used to produce the source message and what language will be used to read 
the messages at the destination. If manipulations are necessary to transform the message data into a format 
acceptable by the receiving application, the user will form a Data Definition file (Ddef) written in DDL and a 
Data Manipulation file (Dman) written in DML. The Ddef file defines the format of the messages passed 

55 between applications, specifically, the integers, strings, arrays, structures, records and bytes that make up 
the output of one application and the input for another application. The Dman file, on the other hand, 
contains the definitions of each data manipulation as described above. Each data manipulation defines the 
operations that must be performed on a source data structure so that it has the format and typing that the 
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destination application can accept. 

3. Designing The Processes 

5 The user designs the integrated system of the invention by determining the tasks or processes required 

by the flow of data. The user also determines how these tasks should be grouped in application adaptors 
and stores this information in the Process Definition configuration file (Proc). Information in the Proc file lists 
the processes that send and receive data, default runstrings and miscellaneous execution information. The 
process logical name is used by the access routines (Appendix A) to reference a particular process 

w definition entry. 

4. Determining Data Format 

The user also determines whether the data exchanged is in file or message format If it is in file format, 
is the user determines what file copy options to use. This information should be stored in a File Definition file 
(Fdef). If it is in message format, it should determine what manipulations and the like are needed. 

5. Setting Links 

20 Finally, the user defines links to associate data definitions and data manipulations with the list of nodes 
where the source data may be produced and the source and destination languages of the data transferred. 
This information is stored in a Link Definition configuration file (Link). The Link file describes the physical 
characteristics of data at the source and the destination of a message and bind specific data or 
manipulation definitions to particular links. The Link definition binds data definitions and manipulations to 

25 source locations and architecture types, source and destination languages and file definitions. 

Thus, configuration in accordance with the invention means describing the applications, nodes in the 
network, processes, files, links and manipulations to the integration device of the invention. This is the 
information gathering process. In a preferred embodiment of the invention, six configuration files 502 (FIG. 
5) are created by a text editor to model the system to be integrated in accordance with the invention. 

30 Once these configuration files are created and validated, the system of the invention is ready for start- 

up. In particular, the run time system of the invention as shown in FIG. 4 must be established on each node 
of the network so that the processes on each of the nodes within the network may communicate with each 
other as specified in the configuration files. In other words, the DMM modules of the invention as shown in 
FiG. 4 must be made node-specific and installed on all the nodes in the integration domain and the 

35 configuration tables 408 loaded into memory. However, before this is done, the integrator designates an 
administration node, for providing functions such as start-up, shut-down and security, and preferably, a 
given number of alternate administration nodes are also established in case of failure of the primary 
administration node. The system manager 422 is then used to configure system security and to perform 
startup as will be described below. The user then writes and compiles the application adaptors for the 

40 various processes. However, since the application adaptors require configuration information, configuration 
and application adaptor development can be done in conjunction or in any order. On the other hand, since 
the user may use the command processor to simulate other adaptors for testing purposes, it is preferable 
that the user perform adaptor development as a final step. The user is now ready to start running the 
system of the invention to generate the DMM modules as shown in FIG. 5. 

45 As shown in FIG. 5, the configuration files 502 are loaded onto the administration node. A validation 
program 504 reads in the network definitions (Netw), the process definitions (Proc), the link definitions (Link) 
and file definitions (Fdef) from the configuration files 502. The configuration files 502 must reside in a 
directory identified to validation program 504. Validation program 504 checks the integrity of the configura- 
tion files and converts them into the binary data files 510 required at start-up. The validation program then 

so invokes the DDL compiler 506 to read the data definition (Ddef) and produce a DDL symbol table in 
memory. The DML compiler 508 is then invoked by the validation program 504 to read the data 
manipulation definitions in the Dman file and to generate C source files 512 which contain the C language 
instructions to perform the data manipulation and conversion of the source data to a common data 
representation. The DML compiler 508 then uses data definition information for the DML compiler 508, link 

55 definitions from validation process 504 and manipulation definitions from Dman 502 to generate the look-up 
table C source files 530, the manipulation C source files 512, and the C source index files 514. The C 
source index files contain the list of all C sources generated for the various nodes in the domain. A different 
source file index is generated for each machine type. 
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The validated configuration files 510, the manipulation C source files 51 2, and C source index files 514 
and look-up table C source files 530 thus represent the configuration information in a manner that can be 
loaded into memory but is instead used to build the DMM 412. These files are used by the administration 
node during start-up process 516 to create Configuration Tables which are distributed to all nodes in the 

s integration domain. The C source index files 514, lookup table C source files 530, and manipulation C 
source files 512 are used in forming node-specific data manipulation modules. 

In particular, start-up is initiated on the administration node by invoking the DDLOAD program 518 to 
load the Configuration Tables into memory. The Configuration Tables include (1) a list of nodes in the 
integration domain arid (2) a list of compilation nodes, where a compilation node is defined as a node on 

ro which the integration system compiles the look-up table C source files 530 and the manipulation C source 
files 512 for all nodes belonging to that computer architecture family in order to create the node-specific 
DMM. There must be at least one node defined as the compilation node for each type of computer 
architecture in the integration domain. In other words, a compilation node is provided for each type of 
computer architecture within a heterogeneous computer network environment. Of course, for a homo- 

75 geneous computer network environment, only one compilation node is required. 

Once the Configuration Tables are loaded on the administration node during start-up, start-up process 
516 marks the nodes to be started and asks the system manager to schedule the DMM builder 520 on each 
compilation node. As noted above, there must be a compilation node for each machine type in the system. 
If the compilation node for a particular machine type is not found, an error message is issued and start-up 

20 is halted on all nodes of that machine type. 

At each compilation node, the following start-up activities are conducted by DMM builder 520. The 
DMM builder 520 pulls (copies) the C source index file for its particular machine type along with the 
relevant C sources (look-up and manipulation) and the list of nodes within the network that need a new 
DMM onto the compilation node and compiles the C source files into object modules. The result is a DMM 

25 module 528 on the compilation node which corresponds to the DMM 412 used on that node during run time 
as shown in FIG. 4. The C compiler 524 compiles the manipulation C source files 512 into a customized 
library of object files 526 which is specific to that machine or architecture type. The Compiler 524 compiles 
the look-up table C source files 530 into node specific object files. 

The compilation node then distributes the node-specific DMM module 528 to each node of its machine 

30 type on the network that needs it. FIG. 6 shows how the compilation node distributes the DMMs to all such 
nodes. As shown, the validated configuration files 510, the look-up C source files 530, the manipulation C 
source files 512 and the C source index files 514 are pulled by (copied) the compilation node for forming an 
architecture specific DMM module 528 as just described. This DMM module 528 is then distributed to all 
other nodes (nodes 3-6) of that architectural type on the network which need a DMM, and these nodes, in 

35 turn, notify the compilation node that they have received the DMM. The compilation node passes this status 
to the start-up process. 

In summary, the process performs the following activities on each node, beginning with the start-up 
node: copies the validated files to the node; loads the Configuration Tables into memory; prepares the run 
time programs for start-up; starts/stops the run time programs according to the user's decision; copies a set 

40 of configuration files to all alternate administration nodes; and copies the Manipulation C source files 512, 
the lookup files 530 and the C source index files 514 to all alternate administration nodes. 

FIG. 7 is a summary of the procedure for setting up and starting the integration system of the invention. 
As shown, the user first configures and validates the integration at step 702 and then determines at step 
704 whether application adaptor programs need to be created or modified in order to interface the 

45 application program to the integration system. If so, the application adaptor programs are created or 
modified at step 706 and then compiled at step 708 for linkage into the system at start-up (step 710). The 
user may then test the configuration at step 712 using the command processor, and if the configuration has 
no problems, all nodes may be started up. On the other hand, if there is a problem with start-up, at step 
714 it is determined whether the configuration needs to be changed. If not, the application adaptor 

so programs are modified at step 716, and the modified adaptor programs are then compiled at step 708 and 
once again linked into the system for start-up at step 710. However, if the configuration does need to be 
changed after testing, control branches from step 714 to step 718 where the system is shut down to allow 
for reconfiguration and validation of the Configuration Tables 408. Thus, in the presently preferred 
embodiment, the system is shut down for reconfiguration since the configuration data is linked in during 

55 start-up of the nodes. However, as will be apparent to one of ordinary skill in the art. the configuration may 
be changed and validated during run time without shutting down the system, but it cannot be switched into 
the running system unless the current system is shut down. Once the integrated system is running, control 
may be turned over to the system administrator for daily administrative tasks. 
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DMM RUN TIME OPERATION 

As described with respect to FIG. 5, the data manipulator of the invention preferably comprises a DDL 
compiler which processes data declarations and generates symbol tables for use by other software modules 

5 of the data manipulator. A DML compiler is also provided for processing data manipulation statements 
defined by the users and for generating C source code modules that will be compiled with data encoding 
functions (such as ASN.1 Basic Encoding Rules) in a Common Data Representation Library and with data 
conversion and manipulation functions in a Data Manipulation Library. The object code modules created 
after the compilation will be executed at run time by a module called the data manipulation shell, which 

w determines what type of manipulations are required for a specific message and invokes appropriate 
manipulation modules generated by the DML compiler to transform data into a common data representation 
notation for transmission to a computer with a different architecture. Finally, the data manipulator of a 
preferred embodiment of the invention will include an "unmarshaller" module which is invoked by the 
Incoming Network Manager 318 to decode a message in common data representation format to the local 

75 host data and language representation. 

During operation of the data manipulation module, the data manipulation shell reads a message from its 
in-coming mailbox (from request manager 306) and calls appropriate data manipulations (such as those in 
pseudocode form in Appendix E) to transform the data as requested by the user's application program (i.e., 
to match the destination format). After the message is manipulated, the data manipulation shell sends it to 

20 the Outgoing Network Manager 316 for delivery. At the receiving node, the Incoming Network Manager 318 
gets the message from the network and determines whether an unmarshalling task (such as those in 
pseudocode from in Appendix F) is necessary. If it is, the incoming network manager 318 invokes the 
unmarshaller module. From the message content, the unmarshaller module determines which functions are 
needed and invokes these functions to perform the unmarshalling. 

25 As noted above, the objective of the data manipulation module is to enable the user to transfer data 
between two applications residing on different machine architectures and written in different languages. The 
problem which arises when this is attempted is that the sending and receiving machine* 
architecture/language may emit or expect the data to be in a particular representation or a particular date* 
size or alignment. For example, string representations, boolean representations, row/column major address^ 

30 ing, data size and the like may be language specific, while byte order, two's complement notation, floating 
point (real) representation, character set, data size and the like may be machine-specific. Such differences 
in architectures and languages imply that some sort of data manipulation must be performed on data 
emitted to make it acceptable to a receiving* application. Conversion routines are needed to support this 
data manipulation, and such conversion routines are included within the data manipulation module of the 

35 invention as described above with respect to FIGS. 5 and 6. 

The present invention uses a Common Data Representation (CDR) in which the conversion routines 
needed are written to convert data back and forth from a local machine and language format to a machine- 
and language- independent data format. Thus, a sender of data will convert the data into CDR format and 
send the data. A receiving system will invoke routines to convert the CDR-formatted data into the receiving 

40 system's local data format. Each machine architecture thereby only has to know about how to convert from 
its local machine format to CDR. Moreover, any new machine architecture added to the network only has to 
know the same for its data converting. 

In accordance with the invention, one skilled in the art may design his or her own common data 
representation which will handle all the data types which are to be supported on the network. However, a 

45 presently preferred embodiment of the present invention uses an already existing, standard CDR encoding 
rules entitled OSI ASN.1 Basic Encoding Rules (BER). In particular, a preferred embodiment of the invention 
uses the byte-level "transfer syntax" format specified in ASN.1 for CDR encoding the data described by the 
data definition and data manipulation languages previously described. 

Thus, in accordance with a preferred embodiment of the invention, the data elements transferred 

so between machines are in ASN.1 BER encoding. The problem here is that when an ASN.1 -encoded data 
element arrives on a target system, that data element could be unmarshalled into any one of a number of 
language- specific data types. Thus, a "type attribute ID" must accompany the ASN.1 encoded user data 
element in the message to identify the language-specific data type that the ASN.1 -encoded user data 
element will be unmarshalled into on the target system. These type attribute IDs are also in ASN.1 

55 encoding. A mapping is needed between DDL types and ASN.1 data types. The following is a table of 
presently preferred DDL data types versus ASN.1 encoded data types: 
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DDL Types 


Type Attribute ID 


ASN.1 Types 


Type Attributes 


btt_field 


BITJTELD (0) 


bitstrine 




byte (8-biO 


BYTE (1) 


integer 


shortjnc 


SHORT.INT (2) 


inteeer 


INTEGER (3) 


lonejnt 


LONG.INT (4) 


short.boolean 


SHORT.BOOLEAN (5) 


boolean 


boolean 


BOOLEAN (6) 


lonflL-boolean 


LONGJ300LEAN (7) 


char (8-bit) 


CHAR f8) 


strine 


opaque (8-btt-altened) 


OPAQUE (9) 


octet strine 


real 


REAL (10) 


real 


lone_real 


LONG.REAL (11) 


strine f8-bit chars) 


STRING (12) 


strine 


max leneth 


unsigned bir.field 


LLBIT.FIELD (13) 


bitstrine 




unsiened byte f 8-bit) 


U3YTE (14) 


integer 


unsiened short.int 


U.SHORT.INT(15) 


unsiened integer 


UJNTEGER (16) 


unsiened toneJnt 


U.LONGJNT (17) 


mulripte-dimen array* 


ARRAY (18) 


sequence -of 


record 


RECORD (19) 


sequence 


restrictive type 


packed multiple-dtmen array" 


PACKED.ARRAY (20) 


sequence -of 




packed record 


PACKED.RECORD (21) 


sequence 


restrictive type 



TABLE 1 

*The unmarshalling module assumes that the code doing the 
marshalling will place thfe elements of the multiple-dimensioned 
array into the row-/column-major order for the target language. 
In other words, the unmarshaller assumes that the elements of the 
ASH.l array are in the proper row-/column-major order for the 
target language. It does NOT do reordering of array elements* 

The parenthesized ( ) numbers after the type attribute ID name 
indicate the numerical value of the type attribute ID that will be 
used in the code. 

As shown in Table 1, the type attribute ID is a name identifying the target DDL type of the ASN.1 type. 
The number after the name is used in the source code to represent that ID. Besides the type attribute IDs, 
the type attributes also include extra information that is transferred with the ASN.1 data type to allow for the 
correct unmarshalling by the receiving node into the target DDL type. ASN.1 data type format does not 
have a place for such information. For example, the ASN.1 string type data element has a field to indicate 
the current size of the string value, but no field to indicate what the maximum size of the string can be. This 
maximum size information is type attribute information. Because both the type attribute IDs and type 
attributes are extra information needed in addition to the actual ASN.1 encoded user data, they have both 
been conceptually lumped together under the title of "type attributes" herein. 

"Marshalling" of data involves converting data in a local format into a machine and language 
independent CDR format as described above. Such marshalled data can then be sent to an "unmarshalling 11 
module resident on this or another system in the network. The unmarshalling module will then convert that 
data into the local machine- and language- dependent format. In accordance with the invention, a 
marshalled message is broken down into two main parts: a static format message header and a dynamic 
format application data part. The division of these parts is based on whether the part contains predefined, 
static format data, or whether it contains application-bound data that can have any type of format. The 



13 



EP 0 456 249 A2 



message header contains administrative information needed to transfer the message, such as 
source/destination node names, operation flags, target process logical names and the like. It also contains 
the information necessary to carry out the specific functions such as send a file, start/stop a process, return 
status to the machine application server, and the like. The dynamic format part, on the other hand, varies 
5 depending on the application data being transferred. 

The dynamic part of the message contains significant subfields. These are shown as follows: 



Static Message Part 
Data Buffer Header/User Data/Type Attributes 



75 The data buffer header contains information needed to initialize the unmarshalling process, while the 
user data is the ASN.1 encoded "pure" data that is expected by the receiving application. Type attributes, 
on the other hand, are extra, non-ASN.1 information needed to help unmarshall the user data. For example, 
this type attribute data will be node specific information which allows the user data to be converted to the 
local data format type. Preferably, the user data is kept in one buffer and the type attribute data is 

20 contained in another data buffer during marshalling to facilitate appending (copying) of the type attribute 
data for a given primitive to the associated user data. The data buffer header, on the other hand, may 
contain information such as at what offset do the type attributes start and what is their total length. Detailed 
examples of the implementation of marshalling with this type of buffer format can be found in Appendix E. 
The user data will be marshalled into ASN.1 data elements according to the DDL-type/ASN.1-type table 

25 given previously and the ASN.1 Basic Encoding Rules (BER). 

The data manipulation module marshalls the data in accordance with the invention by building a library 
called a Marshalling Routines Library (MRL). Each MRL will be customized for the particular machine 
architecture. Thus, there will be one MRL version per machine architecture type supported. In a preferred 
embodiment, the MRL assumes that it will be called by C language code compiled by a C compiler 

30 supported by the integration system for that particular computer architecture. Also, the MRL is not designed 
to be a run time shared library, and instead, the library code will be linked into the DMM's code at link time 
as described above. 

Code emitted by the DML compiler 508 will do the following marshalling steps: 
1 . Start the marshalling process by marshalling the header; 

35 2. Marshalling the source data elements in the sequential order that they will appear in the buffer at the 
destination program; and 

3. When finished marshalling all data elements, marshalling the trailer (if present). For ease of use, the 
marshalling routines preferably provide two buffers, a source buffer for holding the source localized data 
element, and another buffer, the target buffer, for holding the marshalled data elements. 
40 The "unmarshalling" routines of the invention will now be described. Unmarshalling is the process by 
which data in the machine-independent CDR format is converted into some target machine and language 
format. The type of information used by the unmarshalling routines is of two types. The first type is 
information that can change with the use of the data such as signed/unsigned, packed/not packed, and the 
like. This information will be passed with the data in the CDR data stream as type attributes. The other type 
45 of information is stable information such as data alignment and byte/word sizes. This information may fit 
naturally into static tables. 

As each CDR data element is being read, it is unmarshalled using unmarshalling routines which are 
built into a library called the Unmarshalling Routines Library (URL). As with the MRLs, each URL will be 
customized for a particular machine architecture. Thus, there will be one URL version per machine 

so architecture type supported. Much of this customization can be handled through changes in values as the 
Library is built As with the MRL, the URL is not designed to be a run time shared library. Rather, the library 
code will be linked into the INM's code at link time. 

A selective low-level routine will be invoked to unmarshall a corresponding data element. The decision 
of which low-level routine to invoke will be based on what type of CDR data is in the CDR data stream. 

55 Thus, there must be a main routine built on top of these low-level routines that will look at the next data 
element in the CDR stream and use the type attribute ID of ihat element to select the low-level 
unmarshalling routine to invoke. Such a routine is straightforward and may be readily designed by one 
skilled in the art. 
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Language-specific information about data type sizes and alignments and pointers to the conversion 
routines to invoke for the DDL type at the destination node are organized into a 2 x 2 matrix called a 
Language Table. There is one Language Table per language per machine type. Preferably, the rows are 
DDL types, while the columns are the related localized data element size, alignment and pointer to the 
specific DDL unmarshalling routine to call: 



10 



is 



| DDL Type j 


She | 


Alignment u j 


pointer to j 
marshalling motif e 


char 


2 


2 


ptr 




int 


4 


2 


P* 










real 


8 


8 






unsigned int 


4 


2 


ptr 





20 



cdn.to.uJnt (axe, alignment); 

TABLE 2 



25 



In order to determine which Language Table to choose upon receipt of data, the header of the CDR is 
examined for a byte of information that selects what the target language will be. This byte is used to set a 
global pointer to point to the Language Table to be used to unmarshall that message. To go from this byte 
value to a global pointer can be done with the following table of pointers to Language Tables: 



30 



•ource.buffer 
header 



35 



40 



45 




TABLE 3 



so The Language Table Pointer Table (ltp_table) is set up when the unmarshalling code starts up. During 
the start of unmarshalling a message, the target language byte value is used as an index into ltp_table to 
retrieve a pointer to a Language Table. A global pointer is set to point to this Language Table, which is used 
by the unmarshalling code to convert the remainder of the message. 

It would be easy enough to have a global pointer pointing to the selected Language Table. However, a 

55 problem arises with Pascal and packed data types. Namely, a CDR of a message arriving on a system with 
a target language of Pascal may have a mix of packed and unpacked data elements. Each packed versus 
unpacked data type requires its own size and alignment information in the Pascal Language Table. Thus, 
the Pascal Language Table would have to contain double the amount of information of the other Language 
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Tables. This would also require special checking to handle packed data elements since column indexes into 
the Pascal Language Table would have to be different to access the extra information for packed 
sizes/alignments for data elements. Since it is desired to minimize the amount of special handling and 
checking for Pascal packed types, the packed Pascal may be treated as if it resided in another Language 
Table. Then, by providing a semi-transparent mechanism for dynamically accessing between either the 
packed or unpacked versions of the Pascal Language Table, the code will be able to run much smoother 
and faster. The existence of the extra packed Pascal Language Table should also not affect how other 
languages' Language Tables are accessed. The ltp_Jable proposed looks like the following: 
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TABLE 4 



The byte out of the header of the source buffer is used as an index into the Itp table as shown in 

35 Table 4. This index is saved in a global variable; therefore, with this index, one knows which target language 
will be unmarshalled to. Also, the entry the index selects contains two pointers— one to a packed version of 
the Language Table, and another to an unpacked version of the Language Table. This only applies to the 

Pascal entry in Itp table; the other languages have a NULL pointer for the packed pointer. 

When the unmarshailing process comes across a packed array/record type attribute ID (Pascal must be 

40 the target language), this type attribute is immediately placed in a stack frame. The rest of the fields in the 
stack frame are initialized accordingly from information accompanying the type attribute ID. The unmarshai- 
ling process continues parsing by looking at the next data element in the input buffer. 

However, the data element's size, alignment, and pointer to the conversion routine to invoke must also 
be determined, for although an index to the ltp_table is available, the question becomes which pointer 

46 (column) should be used in that row. This decision depends on whether the previous stack frame was 

packed or not. The corresponding value is used as the index into the selected row of the Itp table. The 

type attribute ID is used as an index into the Language Table to pick up at a particular row the parameters 
and pointer to the routine to invoke. 

As noted above, the user data in the transmitted message is encoded using ASN.1 BER. This is not 

so enough for the receiving side to unmarshai! this data into target language data types, for the type attributes 
and data headers are also marshalled although needed to help in the description. In other words, since all 
parts of the message follow the ASN.1 Basic Encoding Rules, the other parts must be decoded without the 
benefit of the data buffer header and type attributes. This is handled by expecting the data buffer header 
fields to be in a particular order for the data buffer header. Thus, by appropriately placing the data fields, 

55 ASN.1 unmarshailing routines may be called to unmarshall the data containing the version and target 
language data. However, the order of the type attributes field cannot be predicted. Accordingly, the type 
attributes may be unmarshalled on-the-fly during run time as needed. 

Since homogenous data is not marshalled in accordance with the invention, INM 418 must have some 
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mechanism for determining whether a received message has been converted to the CDR. Generally, this 
may be accomplished in accordance with the invention by providing a flag in the received data which 
indicates whether marshalling has been conducted at the sending side. Preferably, the following data 
transmission sequence is used to ensure that INM 418 will recognize whether the received data is in CDR 
5 form. 

In particular, on the sending side data from the source application program gets manipulated and 
marshalled by DMM 412. DMM 412 sets a flag bit to indicate that the dynamic part of the message has 
been marshalled. DMM then sends the message to the ONM 416 on the local node. ONM 416 places a field 
containing the size of the total message in front of the message to be sent. The message is then sent to the 
w destination node. 

On the receiving side, INM 418 receives the incoming messages and first reads from the network the 
total size of a message being received. Then INM reads in the number of bytes specified by the total size 
to obtain the entire message. At the next step, INM 418 looks at the flag field of the message header, and if 
the "marshal!" flag bit in the flag field is set, then the dynamic part of the message is unmarshalled into a 
75 new buffer using a special unmarshalling routine. If the "marshall" flag bit is not set however, this step is 
bypassed and the received data is sent directly to the input queue of the request manager 406. In this 
manner, the request manger 406 will be certain to receive data having the proper formatting for the 
destination application. 

20 SAMPLE CONFIGURATION 

As noted above, before one can configure an integration system in accordance with the invention, one 
must have complete understanding of the system requirements, the system and application capabilities, and 
the integration functions required by the applications. Such information includes (1) the applications that will 
25 be served by the integration system, (2) the data flow (linkage requirements) between those applications, 
(3) the machine types running the applications, and (4) the type of networking used to tie the systems 
together. This information must be supplied to configure the integration system in the manner set forth 
above. 

The following example describes the integration tasks using one portion of a computer-integrated 
30 manufacturing system which manages work orders. The example will be described with respect to FIGS 8 
and 9, where FIG. 8 shows the system to be integrated and FIG. 9 shows the resulting configuration files. In 
the example, there are three applications handling work orders: a material resource planner (MRP) which 
generates work orders and operates on an HP9000/S800 computer (CPU1); a scheduler (SCH) which 
schedules the work and operates on a HP9000/S800 computer (CPU2); and a cell controller (CTL) which 
35 which manages the work and reports work completed and operates on an HP90000/S3000 computer 
(CPU3). These applications are connected over a LAN as shown in FIG. 8. For this example, it will be 
assumed that the MRP application generates work orders and keeps track of work completed and is written 
in C programming language, while the SCH application contains information about the machines, people 
and resources available to work on orders, creates schedules for the work, and is also written in the C 
40 programming language. The CTL application manages the work and is written in FORTRAN. 
The configuration files for the system are formed as follows: 

Network analysis provides information about each of the nodes which must be known before they can 
be used in the integrated system of the invention. This information is used in the Network Definition File 
(Netw) to define the nodes in the integration system. As shown in FIG. 9 ? the network definition file includes 

45 a file entry for each node in the integration system on which at least one application runs. In this example, 
the network definition file preferably describes the following items for each node: its logical name and 
machine type, whether or not it starts at system start-up. whether or not it is the compilation node, the 
maximum number of clone processes it can have, its maximum message area size, the maximum 
percentage of the message area any single process may use. its network type, and its physical node name. 

so For example, application MRP runs on a node having a logical node name CPU1 and a machine type 
HP90000/S800, is designated to start at start-up, is not a compilation node, and is connected to a LAN type 
network. Netw contains similar information for the other nodes except that they are compilation nodes. 

Data flow analysis of the system is then performed to determine the 0 path that message data takes from 
a source application to a destination application. In particular, the user determines what each application 

55 expects as data, what each application that needs to transmit data produces as data, and how the data is 
represented and accessed in each application. The portions of the data that will be sent between 
applications is also determined. In the example, the format and type of data that is exchanged by the three 
applications in the work order management system are determined. It will be assumed that the applications 
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exchange data in both files and message packets. 

Because the data in the example is exchanged between applications written in different languages, the 
user is required to define the types of the data when the system is configured. These data descriptions are 
formed in the Data Definition File (Ddef) which, as noted above/enables messages to be in different formats 

5 or applications to be transformed in different languages at the source application and at the destination 
application to be transformed by using the data definitions in the Ddef file and the manipulations in the 
Dman file. On the other hand, if the data is in file format the user can specify the options of the file transfer 
in a File Definition File (Fdef). 

By way of example, application MRP may transfer a work order file to application SCH containing a 

70 work order number, a parts number, quantity information and due dates. The application MRP may also 
receive completion messages from application CTL after manufacturing is complete. Also, since the 
destination message layout is different from that of the source, a data manipulation must be defined with 
this message transfer. 

Application SCH may transfer instructions in a file for scheduling work from the MRP program and 
T5 dispatch a message to the CTL application containing: part number, quantity information, start date, start 
time, stop date, stop time and work order number. Once again, because the destination message layout is 
different from that of the source, a data manipulation must be defined for this message transfer. Also, 
completion messages from the CTL program after manufacturing is complete may be received by the 
application SCH. Moreover, since the source and destination applications are in different languages, a link to 
20 correct for representational differences between the languages must be identified. 

The CTL application receives dispatched messages from application SCH including: the work order 
number, the part number, the quantity information, the start data and the start time. Work order completion 
messages may then be sent to the application MRP, such messages including: work order number, quantity 
information, part number, completion date and quality information. Also, a work order completion message 
25 containing the work order number, the quantity, the part number and completion date may be sent to 
application SCH. 

At the data flow level, the number of processes the system data transfers require, or the specific tasks 
of those processes varies from one design to another. However, the information gathering procedures and 
mapping to configuration remain the same. For the example, the process configuration files are shown in, 

30 FIG. 9 where the MRP application requires a process MRP01CP to send out the work order file and a 
process MRP02CP to receive completion information. The SCH application also requires two processes: 
SCH01CP to receive the work order file and SCH02CP to send out a dispatch message and receive a work 
order completion message. The CTL application, on the other hand, requires only one process: CTL01FP to 
receive the dispatch message and send out completion messages. Thus, five processes are necessary to 

35 transfer the data between the three applications, and two manipulations (MANIP1 and MANIP3) are required 
because the layout of the data at a destination application is different from the data layout at a source 
application due to language and machine differences. The process information is stored in the Proc file, 
while the manipulation information is stored in the Dman file as shown in FIG. 9. 

Since the work order management example given primarily exchanges messages, the file definition 

40 configuration file (Fdef) contains only FILEDEF1 for the case in which the MRP application sends a work 
order file to the SCH application. When the file reaches the SCH application, it will replace the existing 
target file. 

The next step in the integration process requires that the language and structural details of the 
application data be identified. Once the data structure of both the source and destination applications have 

45 been identified, the user can decide on the manipulations required to transform the source data structure to 
the destination structure and data types. This data information goes into the data definition file (Ddef) and 
data manipulation file (Dman). Thus, the user must know the sizes of the exchanged data so that the 
corresponding DDL data types may be used to define the data in the Ddef file. The following Table 5 shows 
how data sizes in the dispatched message are used to correspond to data types between C and DDL and 

so between FORTRAN and DDL: 
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Source 



Destination 



Language: C 

Sending Buffer: Dispatch message at SCHED 



Language: FORTRAN 

Receiving Buffer Dispatch message at CTL 



C structure 



DDL data definition 
Name: disp_c 



FORTRAN 



DDL data definition 
Name: disp_f 



char 

int 

char 

char 

char 

char 

char 



part_no[17] 
qty " 

start_date[7] 
start_time[5] 
stop_datc[7] 
stop_time{5] 
wo_no[ll] 




start_date 
start_time 
stop_date 
stop_time 
wo no 



: string(17] 

: integer 

:string(7] 

:string[5] 

:stringl7] 

:string(5] 

: string[ll] 



mm See below 
for FORTRAN 
definitions 



part_no 
wo no 



start_date 
startjime 
stop.date 
stop.time 



: string[liS] 

: string[10] 

: integer 

:string[6~] 

:string(4] 

:string[6] 

:string[4] 



TABLE 5 



The information from Table 5 may be used to determine the manipulation pattern necessary to transform 
the data in the integration system. These manipulations go into the data manipulation file Dman. For the 
present example, the manipulation statement that is required is a MOVE of the source structure (Disp_c) to 
the destination structure (Disp_f) (i.e., MOVE disp_c TO disp_f). This manipulation statement is contained 
in the example manipulation called Manipl. 

The user is now ready to describe the nodes where the source data defined in the DDL or DML can 
originate. This information is stored in the Link Definition File (Link). The links bind the source and 
destination language types to a specific data definition or data manipulation at validation. At run time, the 
Link file designates the distribution" of node-specific data manipulations to the appropriate nodes. For 
example, Linkl requires Manipl to convert from source language C to destination language FORTRAN for a 
message originating at source node CPU2 and destined for node CPU3. 

For the example given in FIGS. 8 and 9, the Link file defines the four links required for the work order 
management system example. Linkl binds Manipl (the manipulation performed on the dispatch message 
sent from SCH to CTL) to the C language used by the SCH application. Link2 on the other hand, corrects 
for representational differences in the work order complete message sent from the FORTRAN application 
CTL to the C application SCH. The message has the same record format but is in a different language. 

Link2 thus points to the DDL definition of the source data structure (wo comp_f) in the Ddef file. Link3 

binds Manip3 (the manipulation performed on the work order complete message sent from CTL to MRP) to 
the FORTRAN language used by the CTL application. Finally, Linkl defines the link for a file transfer. The 
file transfered, filedefl , is the work order file that the MRP application sends to the SCH application. The 
NULL value indicates that no manipulations are required, only specification of destination file attributes. 
CPU2 and CPU3 receive the DMM modules (at startup) that enable them to handle the transfers. 

FIG. 9 shows the configuration files as created for the work order management system example 
described above and shows how information defined in each file is referenced by the other files. This 
configuration file set is validated before it is used in startup in the manner described above with respect to 
FIG. 5. Thus, DMM 412 is created specifically to handle the manipulation specified by the user in the 
configuration files. For this purpose, these files are validated before startup and loaded (at startup) on each 
node as Configuration Tables as previously described. 

Although an exemplary embodiment of the invention has been described in detail above, those skilled in 
the art will readily appreciate that many additional modifications are possible in the exemplary embodiment 
without materially departing from the novel teachings and advantages of the invention. For example, access 
to a remote database using the invention may be possible by eliminating the dependencies on a specific 
set of database management system calls. Thus, an application accessing another application's database 
through the remote data access routines will be freed from changes should the database structure or the 
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database management system used by the target application change. This can be accomplished through 
the syntactical and structural definition of the target application database in the configuration files. In 
addition, the configuration files of the invention may have domains, where each domain contains a 
configuration for a system running on a physical network. There can thus be several domains operating 
5 concurrently on any physical network, and these domains can be managed by the user in accordance with 
the invention by configuring the nodes into non-overlapping domains. Also, the invention may automatically 
determine the optimal allocation for data manipulation in order to balance the system load. Accordingly, 
these and all such modifications are intended to be included within the scope of this invention as defined in 
the following claims. 
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APPENDIX A 



The following routines are used for initializing or 
removing -communication to the system of the invention: 

- Splnit: Used to initiate communication between the 
system and the calling process* 

- SpEhd: Used to end communication and cleanup 
resources allocated by the system for the calling 
process* 

The following function is used to transfer messages 
between processes: 

- SpSendMsg: Used to send a message to a process* 

The following function is used for transferring files: 

- SpSendFile: Used to copy or append a file to a 
destination file. 

The following functions are used to control system 
processes: 

- SpS tart Process: Used to start a system process. 

- SpStopProcess: Used to stop a system process* 

The following function is used to read incoming 
messages : 

- SpReadQ: Used to read messages from the process* 
incoming message queue. 

The following function is used to control user access 
routine options: 

-SpControl: Used to set user-controlled options for 
the system access routines. 

The following function is used to allow the user to 
access the system error logger: 

- SpErrLog: Used to allow the user to send application- 
specific messages to the system error logger. 

The following function is used to clear the application 
queue* This function should be used with care. 

- SpFlush: Used to set user-controlled options for the 
system access routines. 



21 



EP 0 456 249 A2 



Access Routine Examples 

Splnit - Every process must do an Splnit. In this 
example, Splnit initiates communication between the 
integration system and the process named mrpOlcp* 



int rc; 

int i; 

1nt in list[5], out list[5]; 

int flags; 

char srcprocln[16]; 



for (1-0; i <5; 1++) 
( 

1n_l1st[1]-0; 
outJ1st[1]«0; 

flags -0; 

strcpy (srcprocln, "mrpOlcp"); 

if ((rc«SpIn1t(flags, srcprocln, 1n Hst f out 11st)) !-0) 

{ . 

printf ("ERROR: Splnit of Xs returns %d\n", srcprocln, rc); 
exit(l); 

) 

el se printf ( "Splnit was successful . . *\n" t rc) ; 
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SpEnd - SpEnd ends communication between the 
integration system and a process* 



int rc; 
int flags; 
• 






• 
• 

flags«0; 




1f ((rc-SpEnd(f!ags)) ; l-0) 

printf ("ERROR: SpEnd returns *d\n", 




rc); 


else 




printf ("SpEnd was successful.. An" 


t rc); 



SpSendMsg In this example, SpSendMsg sends a message to Che message buffer called 
SCHWOFILE in the process named schOlcp. 



int rc; 

int 1; 

int in I1st[5], outJ1st[5]; 

int flags; 

char desprocl n [ 1 6 ] ; 

unsigned char dfi1ename[HAXBUFSIZE]; 

char linkname[16] ; 



for (1-0; 1 <5; 
{ 

1n list[l]«0; 
out 1ist[l]«0; 

} 

fl ags-0; 

strcpy (desprocln, "schOlcp"); 

strcpy (dfilename, SCHWOFILE) ; 

strcpy (linkname, ""); 

in list[SpBUF IEN] - strl en (dfilename) +1; 

1n~list[SpTAGT-l; 

if ((rc - SpSendHsg(flags, desprocln, dfilename, linkname. 1n_11st, 
out 11st)) !-0) 
printf ("ERROR: SpSendMsg returns %d\n", rc); 

el se 

printf ("SpSendMsg successful . . ; 
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SpSendFUe In this example, SpSendHIe sends the source file MRPWOFILE to the 
LOG INFO file in the process named schOlcp. It uses the file attributes 
specified in the link file linkfl. 



1nt rc; 

int 1 ; 

1nt injist[5], outJ1$t[5]; 

int flags; ~ 

char desprocln[16] ; 

unsigned char sref ile[MAXBUFSIZE] ; 

unsigned char dfnename[MAXBUFSIZE] ; 

unsigned char desf 1le[MAXBUFSIZE] ; 

char linkname[16]; 



for (i -0; i<5; 

inJist[l]'-0; 
outJist[l] -0; 

flags -0; 

strcpy (desprocln, ■schOlcp") ; 
strcpy (sref He, HRPWOFILE) ; 
strcpy (df ilename, SCHWOFILE) ; 
strcpy (desf He, L0GINF0); 
strcat (desfile, dfilenarae); 
strcpy (linkname, •Unkfl-); 

if ((rc-SpSendF1le(flags, desprocln, srefile, desf1le f Unknane, in list, 
outjist)) !«0) 
printf ("ERROR: SpSendFlle returns %d\n", rc); 

else 

printf ("SpSendFile successful . . An") ; 
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SpSUrtProcesj In this example, SpStartProcess starts the process named schOlcp. 



int rc; 

1nt 1t 

int injist[5], outJ1$t[5]j 

1nt flags; 

char desprocln[16]; 

char runstring [128]; 

char execinfo[256]; 



for (i -0; i <5; i++) 

C in list[l]-0; 

out list[l]-0; . 

) 

flags -0; 

strcpy (desprocln, "schOlcp"); 
strcpy (runstring, ""); 
strcpy (exednfo, "■); 
inj istCSpPASSWD.NUM] - 100; 



1f ((rc- SpStartProcess (flags, desprocln, runstring, exednfo, 1nJ1st, 
out J 1st)) 1-0) 
pri ntf ("ERROR: SpStartProcess returns *d\n , rc) ; 



else 



pri ntf ("SpStartProcess successful . . .\n") '» 
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SpStopProcess In this example, SpStopProcess stops a process named "test02" when the 
calling program receives the SIGUSR1 interrupt. The password number 
tnjist parameter must match the password number specified for this 
process in the Process DeCnition configuration file to stop this process. 



int flags; 

char desprocln[16] 

Int inJ1st[5] f outJ1st[5]; 



flags -0; 

strcpy(desprocln, "test02"); 
1n 11st[SpPASSWD NUM] - 100; 
1n~l 1st[SpST0P_STG] - SIGUSR1 ; 

1f ( (re « SpStopProcess (flags, desprocln, Injist, out_I1st)) !-0) 

printf ("ERROR: SpStopProcess returns %d\n", rc); 
exit(l); 

else 
C 

printf ("SpStopProcess was successful An") ; 
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SpReadQ In this example, SpReadQ reads the incoming message area and places 
the message with the tag value of 1 in the buffer area. 



1nt rc; 

int 1; 

Int 1njist[5], outJ1st[5]; 

int flags; 

char procln[16]; 

unsigned char buf fer[MAXBUFSIZE] ; 



for (i*«Q; 1<5; i++) 
{ 

1n_list[l]-0; 
out list[l]«0; 

} 

flags -0; 

1n Hst[SpBUF LEN] -MAXBUFSIZE; 
in~list[SpTIM&)UT]«0; 
1n~list[Sp LOWER TAG] - 1; 
in!list[SpUPPERlTA6]-0; 

1f ((rc-SpReadQ(flags,procln, buffer, IrTllst, outjlst)) !«0) 
printf ("ERROR: SpReadQ returns %d\n\ rc) ; 

else 

printf ("SpReadQ successful . . An") ; 
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spControl 

In this example, the SpControl function parameter 
SpSET_ FILE_ NOTIF notifies the calling program when a file sent 
through the system is available to it. The calling program is 
notified by means of the interrupt SIGUSRl specified in the 
in_ list parameter. 



int func; 

1nt 1n list[5], outJ1st[5]; 

1nt i;~ 

void handler_routine( ); 

static struct slgvec slgjidlr • {handlerjroutine, 0 f 0); 

/* Set up a handler for SIGUSRl signal. V 
sigvector(SIGUSRl, isigjidlr, 0); 



func - SpSET_FILEJ<OTIF; 
for (i - 0; 1 < 57 i++) 
C 

1nJ1st[1] - 0; 
out Hst[1] - 0; 

) 

in_list[0] - 1; 
inJ1st[l] - SIGUSRl; 

1f ((rc - SpControl (func, HULL, 1n_11st, outjist)) 1-0) 

prlntf ("ERROR: SpControl of %s returns Xd\n\ procln, rc); 
ex1t(l); 

) 

else 
{ 

prlntf ("SpControl was successful... \n", rc); 



void handler routine ( ) 
{ 

printf("In handler routine 

) 
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SpErrLog 

This example shows using SpErrLog to include a user* 
written error message in the system's error logger. 



char errmsg[MAXMSGSIZE]; 
int errmsglen; 



strcpy(errmsg, "User Error Msg: Frorarecvstop process at stepl."); 
errmsglen - strlen(errmsg) ; 

1f ((rc«SpErrLog(errmsg t errmsglen)) !-0) 

printf ("ERROR: SpErrLog returns %d\n\ rc); 

else 

printf ("SpErrLog was successful .\n") ; 



SpError 

In this example, SpError retrieves an ASCII message 
buffer corresponding to a system error number. 



1nt rcl; 
int rc; 

char errmsg[MAXMSGSIZE]; 



1f ((rcl -SpError (rc, errmsg)) !«0) 

printf ("ERROR: SpError returns %d\n\ rcl); 

else 

printf ("Errormsg is%s"» errmsg); 
exit(l); 
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SpFlush SpFlush flushes pending request and clears the timeout list for the 

process* Use it only if your adaptor uses an interrupc-handling routine 
that needs to do a iongjmp when it is called. 



5 


jmpbuf s1gnal_jrapbuf ; 
• 




10 


* 

set jmp (si gnal_ jmpbuf) ; 
* 




15 


• 
• 

/♦This section of the program describes an infinite waltuslng 
/* theSpReadQ access routine to read Incoming messages. 
• 


V 
V 


20 


• 

/♦The interrupt handler*/ 
void 1nterrupt_handler( ) . 

extern jmp_buf signal_jmpbuf ; 

• 
• 
• 

prlntf ("In signal handler function. \n") ; 




25 




30 


Int rc; 

1f ((rc«SpF1ush(}) !-0) 

prlntf ("ERROR: SpFlush returns Xd\n" 




35 





SpDclGuaranteedMsg This is an example of using SpDeiCuaranteedMsg to delete a guaranteed 

message. 

40 



if ((rc«SpDelGuaranteedMsg()) !-0) 

prlntf ("ERROR: SpOelGuaranteedMsg returns %d\n", rc); 

else 

prlntf ("SpOelGuaranteedMsg successful ..An"); 
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APPENDTX B 

Example Adaptor Programs 

This is a brief description of the functions of the 
adaptors created for the integrated system example, 

mrpoiep The mrpOlcp adaptor initiates the system process 

mrpOlcp which sends a work order file and a message 
containing the destination file name to the schOlcp 
process. The mrpOlcp process also starts up the 
schOlcp program* MrpOlcp uses these calls: Splnit, 
SpS tart Process, SpSendFile, SpSendKsg, and SpEnd. 

schOlcp The schOlcp initates the system process schOlcp that 
uses a SpReadQ call to get the name of the work order 
file sent from mrpOlcp. SchOlcp opens the work order 
file and generates a new dispatch file called SCHDISPF. 
SchOlcp uses these calls Splnit, SpReadQ, and SpEnd*. 
It sets the flat SpDELETE_ALL with the Splnit to delete 
all messages that have been stored for this process. 

sch02cp The sch02cp adaptor initiates the system process 

sch02cp. Sch02cp sends messages to process ctlOlfp and 
receives messages from ctlOlfp. Sch02cp uses these 
calls: Splnit, SpSendMsg, and SpEnd. 

ctlOlfp The ctlOlfp adaptor in FORTRAN initiates the system 

process ctlOlfp that hangs on an SpReadQ call waiting 
for a data message from the process sch02cp. CtlOlfp 
processes the data in the message and returns to wait 
for another SpReadQ call. The ctlOlfp process also 
sends messages to two other processes: sch02cp and 
mrp02cp. 

ctlOlpp The ctlOl pp adaptor is a passed version of ctlOl fp- 

mrp02cp The mrp02cp adaptor initiates the background process 
mrp02cp that hands on an SpReadQ call waiting for a 
data message from the process ctlOlfp. Hrp02cp uses 
these calls: 

Splnit, SpReadQ, and SpEnd. 

These are additional programs created for this work order 
management example: 

exOl.h This is a header file that defines the file directories 
and structures for the adaptors used in this system 
example. 

datagen This is a program to solicit user input for creating a 
work order database. 
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mrpOlcp 



70 



75 



/ 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 




$Source:_ mrpOlcp.c 
SRevisioh: 1.1 $ 

This is a skeleton application adaptor to send a file */ 
to another HP Sockets adaptor. The mrpOlcp adaptor initiates the mrpOlcp*/ 
process which sends a work order file and a message containing the 
destination file name. to the schOlcp process. The mrpOlcp process also 
executes the schOlcp program. MrpOlcp uses these calls: Splnit, 
SpStartProcess, SpSendFile, SpSendHsg, and SpEnd 



V 
*/ 
*/ 
*/ 



20 



/ 



This is the maximum message size HP Sockets allows. 
Change it to the size that the application needs. 



Idefine HAXBUFSIZE 1024 
as #define MAXMSGSIZE 500 

/* Global include files */ 



30 



finclude <stdio.h> 
#1nclude <Sp.c.h> 
finclude "exOl.h" 



/* HP Sockets header include file for C programs */ 
/* Data and file definitions for work order management 
exampl es */ 



35 



/* 



Main program 



V 



40 



ma1n( } 
{ 



/ 



These are suggested parameter definitions for all access routine calls. 



7 



int 

45 int 

unsigned char 
char 



rc; 

buflen; 

buffer[MAXBUFSIZE]; 
prodn[16]; 



/* Access routine return code 
/* Oata buffer length 
/* Data buffer received 
/* Process name initiate 



V 
V 
V 
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char srcprocln[16]; /* Source process name */ 

char desprocln[16]; /* Destination process name */ 

5 char linkname[16]; /* Destination process name */ 

char runstring[128]; /* Runstring for SpStartProcess */ 

char execinfo[256]; /* Execution information for 

SpStartProcess */ 

w 

1nt flags; /* Flag parameter */ 

1nt func; /* Set function for SpControl */ 

char ernnsg[MAXMSGSIZE] ; /* Return error buffer */ 

int errmsgleri; /* Set error message length */ 

1nt in_list[5], /* Additional input parameters */ 

out_11st[5]; /* Additional output parameters */ 

/* ...... These are special parameters used in this program. • */ 

20 

int Is 

unsigned char srcf1le[MAXBUFSIZE]; /* Source file name */ 

unsigned char desfile[MAXBUFSIZE]; /* Destination file name */ 

unsigned char dfilenarae[MAXBUFSIZE]; /* Destination file name only */ 

25 

/* «— -— — — 

Start communications with HP Sockets. Set up the parameters and 

make the Splnit call. 

30 ——«——— — — — V 

for (i - 0; i < 5; 1++) 
{ 

fnjist[1] • 0; 
out_l1st[i] - 0; 

35 ) . 

flags ■ 0; 

strcpy (srcprocln, ■rarpOlcp") ; 

^ 1f ((rc - Splnit(flags, srcprocln, injist, outjist)) !« 0) 
C 

printf ("ERROR: Splnit of Xs returns %d\n", srcprocln, rc); 
ex1t(l); 

} 

45 else 

printf ("Splnit was successful rc); 
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After each call, reset the parameters. Hake the SpStartProcess 
call to execute schOlcp. 



V 



10 



15 



20 



25 



for (i - fr? i < 5; i++) 
{ 

1njist[1] - 0; 
out list[i] - 0; 

} 

flags - 0; 

strcpy(desprocln, "sch01cp"); 
strcpy( runstring, ");- 
strcpy(exednfo, "); 
inJI1st[SpPASSWDJUJM] • 100; 



/* Use default runstring in proc.def 
/* Use default execution info in proc-def 
/* Password number 100 was defined in Proc.def*/ 



V 
V 



if ((rc - SpStartProcess (flags, desprocln, runstring, execinfo, 

injist, outjist)) !« 0) 
printf(" ERROR: SpStartProcess returns Xd\n n , rc); 

else 

printf ( "SpStartProcess successful . * An") ; 



30 



Send file with wait. We use the 60 second default timeout. 
If you need a longer timeout value, use SpControl to 
set up the timeout value* 



V 



for (1 - 0; i < 5; 1++) 

35 { 

1njist[i] - 0; 
out list[i] - 0; 

} 

flags ■ 0; 

strcpy(desprocln, "schOlcp"); 

strcpy(srcfile, MRPWOFILE); 
45 strcpy(dfilename t SCHWOFILE); 
strcpy(desfile, LOGINFO); 
strcat(desfile, dfilename); 
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strcpy(linkname, "linkfl"); 

1f ((rc • SpSendFtle(flags, desprocln, srcfile, desfile, linkname, 

Injist, outjist)) !- 0) 
printf ("ERROR: SpSendFiTe returns *d\n", rc); 

else 

printf C'SpSendFtle successful . . An"); 

After the file has been sent, bundle a message that 
contains the destination file name. Send this message 
to the destination process. 



for {i - 0; i < 5; i++) 
{ 

injist[i] - 0; 
out Hst[i] - 0; 

} 

flags » 0; 

strcpy (desprocln, "schOlcp"}; 

strcpy( srcfile, MRPWOFILE); 
strcpy(dfilename, SCHWOFILE); 

strcpy (linkname, ""); 

inJist[SpBUF LEN] - strlen(dfilename) + 1; 
inJist[SpTAG] - 1; 

if ((rc - SpSendHsg( flags, desprocln, dfilename, linkname, in list, 

outjist)) !-0) 

35 { 

printf ("ERROR: SpSendHsg returns Xd\n", rc); 

} 

else 

printf ("SpSendMsg successful . • An*); 



/* m ..« End communications with HP Sockets */ 
flags • 0; 

if ((rc • SpEnd(flags)) !-0) 

printf ("ERROR: SpEnd returns !td\n", rc); 



else 

printf ("SpEnd was successful An", rc); 

> 
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schOlcp 



/* SSource: schOlcp.c V 

/* JRevision: 1-1 $ V 

/* V 

/* This program initiates the schOlcp process that uses a SpReadQ call */ 

/* to get the file name of the work order file sent from the mrpOlcp process. */ 

/* It opens this work order file and generates a new dispatch file */ 

/* called SCHDISPF, SchOlcp uses these calls: Splnit, SpReadQ, */ 

/* and SpEnd. It sets the flag SpOELETE_ALL with Splnit to */ 

/* delete all messages that have been stored for this process . */ 

/* V 



This is the maximum buffer size allowed by HP Sockets. 
Change it to the size that the application needs. 

--— ......----...-...-......-«.-.-«—.—-«—— */ 

Idefine MAXBUFSIZE 1024 
Idefine MAX MSGS I ZE 500 

/* Global include files "*/ 



# Include <stdio.h> 
# include <signal.h> 
Unclude <time.h> 

#include <Sp.c,h> /* HP Sockets header include file for C programs */ 

#include "exOl.h" /* Oata and file definitions for work order management 

examples V 

/* Function: process.fi le */ 

/* Parameter: filename */ 

/* Return: normal • O f error - -1 */ 

/* V 

/* Description: This function reads a work order file */ 

/* and generates a dispatch file. */ 

/* V 

/* argument meaning */ 
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/* — V 

/* filename name of the work order file */ 

/* on the SCHED application */ 

/* V 

f * *** * * ** ** * ******* *** ** ***** * * * * a t * ** * ** * ** y 

1nt process_file(filename) 
char *f11ename; 

( 

FILE *wo_fp, /* file descriptor */ 

*disp_fp; /* file descriptor */ 

wojrec *woj>tr, wo_buf ; 

dispjrec *disp_ptr s disp_buf; 

int i; 



long cur_time; /* The current time (seconds since Jan 1, 1970)*/ 

char *char_strj)tr; 
char time_str[5] ; 
25 char date_str[7]; 

/* Get the system's time. — — */ 

cur_time - time((long *) 0); /* Get the system's time* */ 
char_str_ptr - nl^cxtimet&cur^time, "XySmXd"); 
strncpy(date_str, char_str_ptr, 7); 

d1sp_ptr • &disp_buf; 
wo_ptr - &wo_buf ; 



Open the work order file for a read «• */. 



if( (wo_fp - fopen (filename, "r"}) ~ NULL) 
{ 

printf ("Could not open work order file %s.\n", filename); 
retum(-l) ; 

} 

/* «.««• Open the dispatch file for a write --»* */ 

else if ( (disp_fp « fopen(SCHOISPF, V)) — NULL) 
( 

printf ("Could not open dispatcher file %s.\n", SCHOISPF); 
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return (- 1) ; 

) 

/* ...... — «-.——— — ———————— 

Simulate a schedule system application that generates dispatch information. 



while ((i - fread(wo_ptr, s1zeof(wo rec), l t wo_fp)) — 1) 
C 

pr1ntf(*In fread loop.\n*)» 
strcpy (dlspjbuf .wojio, wo_ptr->wo_no) ; 
d1sp_buf .qty » wo_ptr->qty; 
strcpy(dispJ>uf.partjio t wo_ptr->part_no) ; 
strcpy (d1sp_buf .start_date, date_str) ; 
strcpy (dispj>uf.start_time t ■0800"); 
strcpy (d1spj>uf .stop_date f date_str) ; 
strcpy(disp buf.stop time, "CgoO"); 

1f((i - fwrite(dispjtr, sizeof(disp rec), 1, disp fp) ) !- 1) 
{ 

printf("fwr1te error for *s.\n\ SCHDISPF); 
return (-1); 

} 

) 

fclose(wo fp); /* Close work order file */ 

fclose(d1sp_fp); /* Close dispatch file */ 

} 

/* «— Main program — — */ 

main() 
C 

/* ————————————————————————— 

These are suggested parameter definitions for all access routine calls. 



int rc; 

int buflen; 

unsigned char buffer [MAX8UFSIZE]; 

char procln[16]; 

char srcproc1n[16]; 

char desprocln[16]; 



/* Access routine return code 

/* Data buffer length 

/* Data buffer received 

/* Process name initiate 

/* Source process name 

/* Destination process name 
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char 

char 
char 



1nt 

1nt 

char 

int 

1nt 



linkname[16]; 

runstring[128] ; 
execinfo[255]; 



flags; 
func; 

errmsg[MAXHSGSIZE]; 
errmsglen; 
1nJ1st[5] t 
out_l1st[5]; 



/* Destination process name 



V 



/* Runstring for SpStartProcess */ 
/* Execution information for 

SpStartProcess */ 



/* Flag parameter 

/* Set function for SpControl 

/* Return error buffer 

/* Set error message length 

/* Additional input parameters 



V 
V 
V 
V 
V 



/* Additional output parameters */ 



/* «•«•— These are special parameters used in this program. 



V 



int 
int 



1; 

still have work « 1; 



/* True for do loop 



V 



Start communications with HP Sockets. Set up the parameters and 
make the Splnit call* 



for (i - 0; i < 5; i++) 
{ 

1nJist[iJ - 0; 
outJ1st[i] - 0; 

} 

flags - SpDELETE_ALL; 
strcpy( srcprocln, "schOlcp"); 

if ((rc ■ Splnit(flags, srcprocln, in list, out_list)) !- 0) 
{ 

printf(" ERROR: Splnit of *s returns Sd\n", srcprocln t rc) ; 
exit(l); 

} 

else 

printf(" Splnit was successful • An" i rc); 



Oo an SpReadQ call to get the name of the work order file 
in the message sent by the mrpOlcp program. 



50 



55 



BNSDOCID:<EP 04S6249A2> 



40 



EP 0 456 249 A2 



,„ ..... ...... ............... =.-- V 

for (i - 0; i < 5; i++) 
( 

1n_11st[1] - 0; 
out 11 sty] - 0; 

} 

flags • 0; 

1n Hst[SpBUF LEN] - HAXBUFSIZE; 

in Hst[SpTIMEOUT] - 0; /* Set timeout forlnfinite wait. */ 

"~ /* Default is 60 seconds. */ 

1nJ1st[SpL0WER TAG] - 1; 
1nJ1st[SpUPPER_TAG] - 0; 

1f ((rc - SpReadQ (flags, procln, buffer, injist, outjlst)) 
!- 0) 

printf(" ERROR: SpReadQ returns *d\n\ rc); 
else 
{ 

pr1ntf("F1le Ss rece1ved.\n", buffer); 

process_file (buffer); /* Call the function defined above 

) 

/* ..... End communications with HP Sockets •»»«• */ 
flags - 0; 

for (1-0; 1 < 5; 1++) 
( 

in_list[1] - 0; 
out I1st[i] - 0; 

) 

if ((rc - SpEnd(flags)) !- 0) 

pHntf ("ERROR: SpEnd returns %d\n", rc); 
else 

printf ("SpEnd was successful .\n") ; 

} 
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SCh02cp 



Sourca: 
SRevision: 



sch02cp.c 
1.1 $ 



This 1s an application adaptor to send messages to 
another HP Sockets adaptor. The sch02cp adaptor Initiates 
the sch02cp process which sends messages to process ctlOlfp 
and receives messages from It. Sch02cp uses these calls: 
Splnit, SpSendMsg, and SpEnd. 



* *********** * * **** * 



r 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 

/* — 

This 1s the maximum buffer size HP Sockets allows. 
Change it to the size that the application needs. 



f define MAXBUFSIZE 1024 
fdefine HAXMSGSIZE 500 

/* Global Include files */ 

# Include <std1o.h> 



****************************** > 



V 
V 
V 

*/ 
*/ 
*/ 

V 
V 



V 



Unclude <Sp.c.h> 
#1nclude "exOl.h" 



/* HP Sockets header include file for C programs */ 
/* Data and file definitions for work order management 
• examples */ 



Main program 



V 



main() 

( 

/* — ■ 



These are suggested parameter definitions for all access routine calls. 



V 



1nt 
int 

unsigned char 
char 



rc; 

buflen; 

buffer [MAXBUFSIZE] ; 
procln[16]; 



/* Access routine return code 
/* Oata buffer length 
/* Oata buffer received 
/* Process name initiate 



V 
V 
V 
V 
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20 



30 



char 


srcprocln[l6j; 


/ 


oOLirCc process name 


*/ 


char 


desprocln[l6]; 


/* 


Destination process name 


V 


char 


linkname[16]; 


V* 


Destination process name 


V 


char 


runstring[128]; 


/* 


Runstring for SpStartProcess 


V 


char 


execinfo[2S6]; 


/* 


Execution information for 








SpStartProcess 


V 



ro 1nt flags; /* Flag parameter */ 

int func; /* Set function for SpControl */ 

char errmsgCMAXMSGSIZE]; /* Return error buffer V 

1nt ernnsglen; /* Set error message length */ 

int 1nJ1st[5], /* Additional input parameters */ 

75 out_list[5]; /* Additional output parameters V 



/* ——These are special parameters used in this program. 

1nt i; 
char contchar, 
dummy [80]; 

disp_rec *disp_ptr, disp_buf; 

25 wo_compl_s_rec *comp_ptr> compjwf ; 

FILE *dispj r p; 



dispjtr - &disp_buf; 
comp_ptr - &comp_buf ; 



Open the dispatch file for a read •-»■» */ 



os if ( (disp fp - fopen(SCHDISPF f "r")) — NULL) 
{ 

printf("Could not open dispatcher file %s.\n\ SCHDISPF); 
exit(l); 

<o > 

/* .---...-..«.--«..««"----.-«-.««-"«««— 

Start communications with HP Sockets, Set up the parameters and 
make the Splnit call. 

45 — — ——————————-———--...-«..--- */ 

for (i - 0; 1 < 5; i++). 
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c 

1njist[i] - 0; 
out I1st[i] - 0; 

} 

flags - 0; 

strcpy(srcprocln, "sch02cp*); 

1f ((rc - Splnit(flags t srcprocln, injist, outjlst)) I- 0) 

pr1ntf( "ERROR: Splnlt of Xs returns %d\n", srcprocln , rc); 
exit(l); 

} 

else 

pr1ntf(" Splnit was successful .-An", rc); 



/* — 

This 1s the area where the data from the application should 
20 be accessed (the file 1s read, the shared memory area 1$ 

accessed, etc)- This portion is application-specific. 

This data should be placed in the buffer variable "buffer" f 
and the number of bytes should be put into variable "buflen" 



/* — — Initialize the continuous flag to yes — — */ 

contchar - 'y'; 

/* — — Read the dispatch record .-•«- */ 

while ( ((i - fread(disp_ptr, sizeof(disp_rec), 1, disp_fp)) — 1) 
1* (contchzr 'y') ) 

( 



printf("Do you want to send this dispatch record to control systea?\n"); 
contchar - getchar(); 
gets (dummy) ; 
if (contchar — 'y') 
^ { 

"5 Use SpSendHsg to send the dispatcher buffer to a FORTRAN 

controller program. 

... ............... —- ~— ....... ............... v 
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for(i - 0; 1 < 5; 
C 

1n I1st[i] - 0; 
out I1st[1] - 0; 

} ~ 

flags - SpNOUAIT.FLAG; 
strcpy(desprocln, "ctlOlfp"); 
strcpy(11nkname, "linkl"); 
1n Hst[SpBUF_LEN] - sizeof(disp_rec) ; 
1nJist[SpTAG] - 10; 

1f ((rc - SpSendMsg (flags, desprocln, disp_ptr, Unkname, 
1n 11st, out list)) !- 0) 

{ 

printf( "ERROR: SpSendMsg of returns «d\n", rc); 

) 

else 
( 

printf ("SpSendMsg successful .. .\n") ; 

/* » — — ———————— 

Oo a ReadQ with a long wait to get the work order complete 
message from the cell controller application. 

« — .......... */ 

for (1 - 0; 1 < 5; 1++) 
{ 

in list[1] - 0; 
out I1st[i] - 0; 

) 

flags - 0; 

1n_I1st[SpL0WER_TAG] - 0; 

in 11st[SpBUFJ.£N] - sizeof(comp_buf) ; 

inJistCSpTIMEOUT] - 0; /* Infinite wait. Oefault 1s 60 sec */ 

If ((rc - SpReadQ( flags, procln, &comp_buf, in 11st, outjlst)) >0) 
{ 

printf (" ERROR: SpReadQ of returns %d\n", rc); 

) 

else 
( 
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printf('SpReadQ successful .\n") ; 

printf("The previous work order had been completed.\n") ; 
prlntf ("wo_comp_wo_no - %s\n*\ comp_buf .wo_no); 
printf(*wo_comp_part_no - %s\n", corap_buf .part_no) ; 
printf("wo comp qty « %d\n" t comp_buf .qty) ; 

) 

} 

} 

> 

/* — ~ End communications with HP Sockets — — */ 

1f ((rc - SpEnd(flags)) 1- 0) 

prlntf ("ERROR: SpEnd returns %d\n\ rc); 
el se 

printf(" SpEnd was successful .\n". rc); 

} 



46 



EP 0 456 249 A2 



CtlOlfp 

FORTRAN programs on the HP900Q/S800 require the 
LTTHRAL^ALIAS ON directive shown in this example. This directive 
specifies that any external names in an ALIAS directive are processed as 
they appear, that is, they are neither upshifted nor downshifted. The 
default is OFF and external names are upshifted or downshifted according 
to the UPPERCASE directive setting. Refer to the HP FORTRAN 77 
Reference Manual (Pan number 5957-4685). 



SLITERALJU.IAS ON 

c c 

C Source: ctlOlfp.f C 

C JRevision: 1.1 S C 

C C 

C This is a FORTRAN application adaptor that initiates the C 

C process ctlOlfp which hangs on an SpReadQ call waiting for C 

C a data message from the process sch02cp. CtlOlfp processes C 

C the data in the message and returns to wait for another C 

C SpReadQ call. The ctlOlfp process also sends messages to C 

C .two other processes: sch02cp and mrp02cp. C 

program ctlOlfp 



$INCLUDE 'Sp.f.h' 



integer 


rc 


integer 


bufl en 


character 


buffer(1024) 


character*16 


procln 


character*16 


srcprocln 


character*16 


desprocln 


character*16 


linkname 


character*! 28 


runstring 


character*256 


execinfo 


Integer 


flags 


integer 


func 


character*25S 


errmsg 


integer 


errmsglen 


integer 


timeout 
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Integer . ilist(5), olist(S) 
C ****** Declaration section ****** 

5 

Integer 1 

character*1024 msgbuf 

10 

C Field definitions (dispatch information) for main example 

character*16 partjio 

character*10 wo_no 

75 integer qty 

character's start jiate, stop_date 

character*4 start_time, stop_time 

2Q equivalence (msgbuf f buffer) 

equivalence (buffer(l), partjio), (buffer(17), wo no), 
+ (buffer(29) f qty)7 (buffer(33), start date), 

♦ (buffer(39), start_time), (buffer(43), stop date), 

+ (buffer (49), stop_time) 

25 

character outbuf{38) 
C Work complete information 

30 ■ 

character*18 c_part_no 
characters 2 c~wo_no 
integer c_qty 
characters c_date_comp 

35 

equivalence (outbuf(l), cj>art_no), (outbuf(19), c_wo_no), 
+ (outbuf(33), c_qty), (outbuf(37), c^date.comp) 

C Start communications with HP Sockets 

40 

do 10 1-1,5,1 
11ist(i)-0 
olist(1)-0 
45 10 continue 

flags » 0 
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srcprocln « "ctlOlfp" 
C NULL terminate the process logical name like a C string 
srcprocln (6: 6) - char(O) 
rc - spinit(flags, srcprocln, Hist, olist) 

if ( rc .NE. 0) then 

write(*,*) "ERROR: spinit return - \ rc 

goto 999 
else 

write(*,*) "spinit successful" 
end if 

C Use an SpReadQ in a loop to read messages from the 
C schOlcp program 

100 continue 

flags - 0 

ilist(SpLOWER TAG)-0 

il1st(SpUPPER~TAG)«0 

ilist(SpBUF_LEN)-1024 

ilist(SpTIME0UT)-0 

ilist(5)-0 

olist(l)-0 
olist(2)-0 
olist(3)-0 
olist(4)-0 
olist(5)-0 

rc - spreadq(flags, procln, buffer, ilist, olist) 

if ( rc .NE. 0) then 

write(* t *) "ERROR: spreadq fail \ rc 

goto 999 
else 

write(*,*) "spreadq successful" 
end if 
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If we get a message with tag-9999, end the loop 

1f (ollst(SpTAG) .ECU 9999) then 

go to 200 
end if 

Display the message received 
write {*,*) 

write(*,*) "Get dispatch buffer :" 
write(*,*) "part-no - ", partjio 
write(*,*) "wo-no - wo no" 
write <*,*) "qty - \ qty 
write(*»*) "start jiate - ", start jiate 
write(*,*) "starOine - ", starOime, 
write(*,*) "stop_date - ", stop_date 
write(*,*) "stop~time • ", stop~time 

Simulate the work complete message 

write(*,*) 

write(*,*) "***The work order has been completed ***" 
write(*,*) "***Send work order completion info to ***" 
write'(*,*) "***HRP and SCHED applications ***" 
write(*,*) 

Use SpSendMsg to send the work order complete message to 
the mrp02cp process using link3 for data conversion. 

c_part_no - part_no 
c_wo_no - wo_no 
c.qty - qty ~ 
cjjate_comp « "891127* 

flags « 0 

desprocln - "mrp02cp" 
desprocln(6:6) - char(0) 

linkname - "link3" 
linkname(6:6) - char(0) 
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ilist(SpCLONEJD)-0 
ilist(SpTAG)-100 
i11st(SpBUF LENJ-38 
1list(4)-0 
1list(5)-0 

ol1st(l}-0 
olist(2)-0 
ol1st(3)-0 
o!1st(4)-0 
olist(5)«0 

rc - spsendmsg(flags, desprocin, outbuf, linknarae, 111st, olist) 

1f ( rc .NE. 0) then 

wr1te(*,*) "ERROR: spsendrasg fall rc 

goto 999 
else 

write(*,*) "spsendmsg successful" 
end if 

C Use SpSendMsg to send the work order complete message to 
C the schOZcp process using Hnk2 for data conversion. 



30 fl ags 



desprocin - "sch02cp". 
desprocln(6:6) - char(O) 

linkname - "link2" 
1inkname(6:6) • char(O) 

1list(SpCL0NEJD)-0 
1l1st(SpTAG)-l00 
1l1St(SpBUF LEN)-38 
1list(4)-0 
1list(5)-0 



olist(l)-0 
olist(2)-0 
olist(3)-0 . 
so olist(4)-0 
olist(5)-0 
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rc » spsendmsg(flags, desprocln, outbuf, Unkname, 111st, ollst) 

1f ( rc .NE. 0) then 

wr1te(*,*) "ERROR: spsendmsg fail ", rc 

goto 999 
else 

write(*,*) "spsendmsg successful" 
end If 

go to 100 

C End communication with HP Sockets 

200 continue 

rc - spend(flags) 
if ( rc .NE. 0} then 

write(*,*) "ERROR: spend fail ", rc 

goto 999 
else 

wr1te(*,*) "spend successful" 
end If 

999 stop 
end 
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J LIST 0N$ 

{This Pascal version of the ctlOlfp process 1s constructed similarly 
to the FORTRAN version 1n order to make it easy to see the correspondence 
between the Individual Items and "procedures" in the two versions. If 
you use this Pascal adaptor template, you may wish to restructure 
this program to conform to good Pascal programming construction. ) 



PROGRAM ctlOlpp (Input, Output); 



{This Pascal application adaptor (process ctlOlpp) is run as a 
background (daemon) process. It hangs on the SpReadQ access routine 
waiting for the message sent by the scheduling process (sch02cp) that 
the work order is ready to be processed. Process ctlOlpp then sends the 
message that the work order has been completed to sch02cp and mrp02cp.} 



LABEL 999; 

$ INCLUDE '/usr/1nclude/Sp.p.h'$ 



(Header file containing} 
{type definitions for Pascal) 



TYPE 



Stringl6 - string[16]; . 
StringlO - string[10]; 
String6 - string[6]; 
String4 - string[4]; 

WorkOrderln - RECORD 

part_.no: String 16; 
wo_no: StringlO; 
qty: Integer; 
startjiate: StringS; 
start_time: String4; 
stop_date: String6; 
stop'ttnre: String4; 

END; 



(The work order information ) 
(coming from sch02cp) 



DispRecord - RECORO 

CASE b: Boolean OF 

TRUE : (dispchar : SpHsgBufType); 
FALSE: (di spree : WorkOrderln); 
END; 



(Transfer character buffer to record) 
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WorkOrderOut - RECORD {The work order Information } 

c_part_no: string[18]; {going to rarp02cp and sch02cp} 
c_wo_no: string[12]; 
c_qty: Integer; 
c date comp: string [8]; 

END; 

OutRecord - RECORD {Transfer character buffer to record} 

CASE b: Boolean OF 

TRUE : (dispchar : SpMsgBufType) ; 
FALSE: {disprec : WorkOrderOut); 

END; 



VAR 



RC, RN: Integer; 
Flags: Integer; 
UnkName: SpLnType; 
Hist, 01 1st: SpIntArrayS; 
DesProcln t SrcProcln: SpLnType; {Dest 
Charbuf: SpMsgBufType; 
DIspBuf: DIspRecord; 
OutBuf: OutRecord; 
Procln: SpLnType; 



{Return Codes} 



Count: Integer; 



process logical names} 
{Send buffer} 
(Variant record variable} 
{Variant record variable} 
{Receive process logical name} 



SINCLUDE / /usr/1nclude/Sp.p2.h / S 



{Header file containing} 
{type definitions for Pascal} 



BEGIN (Main Program} 



{Start cownunicatlons with HP Sockets by using the Splnit access 
routine to initiate the ctlOlpp process. } 

For Count :- 1 To 5 DO 
BEGIN 

Il1st[Count] 0; 

Ol1st[Count] :« 0; 
ENO; 
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SrcProcln :- 'ctlOlpp'; 

SrcProcln[6] :« chr(O); {Zero pad for C compatibility) 

Flags :- SpDELETE_ALL; 

RC 3pIn1t(Flags, SrcProcln, Hist, OUst); 

IF (RC - 0) THEN 
BEGIN 

writeln; 

write! n('SpIn1t successful'}; 
writeln; 

END 

ELSE 

BEGIN 

writeln; 

writeln(' ERROR: Splnit returns:', RC:5); 
writeln; 

END; 



(Use the SpReadQ access routine in a WHILE loop to hang on a 
message front the seh02cp process. } 

WHILE (true) DO 
BEGIN 

For Count :- 1 To 5 00 
BEGIN 

111 st [Count] :- 0; 

01ist[Count] :- 0; 
END; 

Il1st[SpL0WER_TAG] :• 0; 

Ilist[SpBUF_LEN] :- 1024; {The message buffer size) 

I11st[SpTIME0UT] :- 0; {Number of seconds to timeout) 

Flags :- 0; 

RC :- SpReadQ (Flags, Procln, CharBuf, IList, 011st); 

IF RC - 0 THEN 
BEGIN 
writeln; 

writelnC SpReadQ successful.'); 
writeln; 
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END 
ELSE 

writeln( 'ERROR Number:', RC:5); 

1f (0!ist[SpTAG] - 9999) THEN 
goto 999; 

DispBuf .dispchar :~ CharBuf; 



(Hove the message buffer Information} 
(into the record variable} 
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write! 
write! 
write! 
write! 
write! 
write! 
writel 
wr1 tel 
writel 
write! 
write! 
writel 
write! 



n; 
n( 
n( 
n( 
n( 
n( 
n( 
n( 
n; 

n( 
n; 
n( 
n( 



' Part Number: 
'Order Number:' 
' Quantity:' 
' Start Date: J 
' Start Time:' 
' Stop Date:' 
Stop Time:' 



DispBuf. disprec, 
DispBuf .d1 spree 
DispBuf .disprec< 
OispBuf .disprec, 
DispBuf .disprec. 
DispBuf. di spree, 
DispBuf .disprec. 



part_no); 

wojio); 

qty); 

start jlate); 
start_time) ; 
stopjiate) ; 
stop^time) ; 



The work order has been completed***'); 



'Send work order completion information'}; 
'to processes mrp02cp and sch02cp'}; 



30 



{Use the SpSendMsg access routine to send a message to the 
sch02cp and mrp02cp processes.} 



OutBuf.di spree. c_part_no :• DispBuf .di spree. part jio; 
OutBuf.di spree. c_wo_no DispBuf. di spree, wojio; 
OutBuf.di spree. c_qty :« DispBuf .disprec. qty; 
OutBuf.di sprec.cjjate_comp :- DispBuf .disprec. stopjiate; 
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For Count :» 1 To 5 DO 
BEGIN 

Hi st [Count] 0; 

01 1st [Count] 0; 
END; 



Desprocln :• 'mrp02cp'; 
DesProcln[6] chr(O); 



(Zero pad for C compatibility} 
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LinkName :- 'I1nk3'.; 
L1nkName[6] chr(O); 

Flags :- 0; 

IllsttSpTAG] :- 100; {Tag value) 

Ilist[SpBUFJ.EN] :- 38; {Length of message 1n bytes) 

Charbuf :- OutBuf .dlspchar; 

RC :- SpSendMsg (Flags, OesProcln, Charbuf, LinkName, 111st, 011st); 

IF (RC - 0) THEN 
BEGIN 
write! n; 

writeln ('SpSendMsg successful'); 
END; 

IF RC o 0 THEN 
BEGIN 
writeln; 

writelnC ERROR Number:', RC:S); 
wrfteln 
END; 

IF RC - 0 THEN 
BEGIN 
writeln; 

writeln ('Message sent to process mrp02cp'); 
writeln 
END; 



Oesprocln :- 'sch02'; 
0esProcln[6] :- chr(0); 

LinkName :- 'I1nk2'; 
LinkName [6] :- chr(0); 



Flags :• 0; 
IllsttSpTAG] 100; 
Ilist[SpBUF_LEN] :- 38; 

Charbuf OutBuf .dispchar; 



(Zero pad for C compatibility) 



(Tag value) 

(Length of message in bytes) 
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RC :- SpSendMsg( Flags, DesProcIn, Charbuf, LlnkName, Hist, 01 i 

IF (RC - 0) THEN 
BEGIN 
write! n; 

write! n( 'Message sent to process sch02cp'); 

write! n 
END 
ELSE 
BEGIN 

writeln; 

writeln( 'ERROR: SpSendMsg returns:', RC:5); 
writeln 
END; 



END; 

{Use the SpEnd access routine to end communication with HP Sockets. } 

999: Flags :- 0; 

RC :- SpEnd(Flags); 
IF (RC <> 0) THEN 
BEGIN 
writeln; 

writeln( 'ERROR: SpEnd returns:', RC:5); 

writeln 
END 
ELSE 
BEGIN 

writeln; 

writeln(' SpEnd was successful...'); 
writeln 
END; 

END. {Main Program) 
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mrp02cp 



V 



/* v 

/* Source*: mrp02cp.c V 

/* SRevision: 1.1 $ V 

/* */ 

10 /* This 1s a skeleton application adaptor that initiates the */ 

/* background process mrp02cp that hangs on an SpReadQ call */ 

/* waiting for a data message from process ctlOlfp. MrpOZcp */ 

/* uses these calls: Splnit, SpReadQ, and SpEnd. */ 

is /* another SpReadQ call. */ 

/* */ 
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This is the maximum buffer size HP Sockets allows. 
Change it to the size that the application needs. 

V 

#define MAXBUFS12E 1024 
#define HAXMSGSI2E 500 

/* Global include files */ 

finclude <stdio.h> 

finclude <Sp.c.h> /* HP Sockets header include file for C programs */ 

#include "exOl.h" /* Data and file definitions for work order management 

examples */ 



/* Main program 



main() 
{ 

/* — 

These are suggested parameter definitions for all access routine calls. 

— V 

int rc; /* Access routine return code */ 

int buflen; /* Oat a buffer length */ 
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unsigned char 


buffer[MAXBUFSIZE] ; 


/* 


Data buffer received 


V 


char 


procln[16]; 


/* 


Process name Initiate 


V 


char 


srcprocln[16]; 


/* 


Source process name 


V 


char 


desproc1n[16] ; 


/* 


Destination process name 


V 


char 


t j _ i _ r ^ ^ ^ 

nnlcnarae[16j ; 


/* 


Destination process name 


V 


char 


runstrmgi izsj , 


/ 


Kunsxnng ror ^potarrrrocess 


V 


char 


exectnTOizsoj ; 


/ 


Execution information for 










opo uartrrocess 


/ 


Int 


flags; 


/* 


Flag parameter 


V 


int 


func; • 


/* 


Set function for Sp Control 


V 


char 


errmsg[MAXMSGSIZE]; 


/* 


Return error buffer 


V 


int 


errmsglen; 


/* 


Set error message length 


*/ 


int 


1njist[5] f 


/* 


Additional input parameters 


V 




outJ1st[5]; 


/* 


Additional output parameters 


V 



/* — ..-These are special parameters used in this program. «-»-■-■*/ 
Int it 
wo_complete_rec wo_corap1ete_buf ; 



/* — Start communications with HP Sockets — — — — */ 
flags « 0; 

strcpy(srcprocln t "mrp02cp"); 

if ((rc - Splnit(flags, srcprocln, in list, out list)} !- 0) 
{ 

printf ("ERROR: Splnit of *s returns %d\n\ srcprocln , rc); 
exit(l); 

} 

else 

printf (" Splnit was successful, -An", rc); 



Loop forever, waiting for messages. Stop at the special 
message with tag-9999. Set timeout for SpReadQ to 
an infinite wait. Default is 60 seconds. 

for (;;) 
( 
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for (i - 0; i < 5; 1++) 

( 

injistfi] - 0; 
out I1st[i] - 0; 

} 

flags » 0; 

in 1ist[SpL0WER TAG] • 0; 
inJist[SpBUFJJEN] - HAXBUFSIZE; 
1nJist[SpTIME0UT] • 0; 

if ((rc - SpReadQ(flags, procln, iwo complete buf, 1n list, out_list)) >0) 

C 

printf ("ERROR: SpReadQ of returns %d\n\ rc); 

) 

else 
{ 

printf ("SpReadQ successful . . > 

/* 

When this program receives a message with the TAG 
value - 9999, it breaks out of the FOR loop. 

if (outJist[SpTAG] — 9999) 
break; 

printf ( "From Control System, wo - %% has been completed\n", 

wojzompletejwf .wo_no} ; 
printf(" part-no - Xs, \n qty in ascii « %s\n n , wo_complete_buf .part_no, 

wo_complete buf.qty ascii); 

) 

} 

/* ——--»-« End communications with HP Sockets */ 

if ((rc - SpEnd(flags)) !• 0) 

printf ("ERROR: SpEnd returns Xd\n\ rc); 
else 

printf(" SpEnd was successful .\n") ; 
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exOLh 



/* 1 
/* This ftle defines the file directories and structure for the 
/* example adaptors. 

/ * _____ 



/* Define the file directories. */ 

define HRPWOFILE 7u$r/contr1b/Sp/ref/prograras/swofile" 
define SCHWOFILE Vusr/contrib/Sp/ref/programs/dwofile* 
define SCHDISPF Vusr/contrib/Sp/ref/prograras/dispatch" 
define LOG INFO "/user: password" 

/* Define the structure of the work order record */ 
/* used in the datagen.c and schOlcp.c programs. */ 
/* Datagen solicits the user for this information*/ 
/* which the rarpOl process sends to schOl* */ 

typedef struct 
{ . 

char wo_no[ll]; 
int qty; 
char due_date[7]; 
char partjio[17]; 
}. wo_rec; 

/* Define the structure of the dispatch message record */ 
/* used in the schOlcp.c and sch02cp.c programs. */ 



/* Work order number 
/* Number of parts ordered 
/* Date order is due 
/* Part number 



typedef struct 
{ 

char part_no[17]; 

1nt qty; 

char start_date[7]; 

char start~t1me[5]; 

char stop_date[7]; 

char stop2time[5]; 

char wo_no[Il]; 
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} d1sp_rec; 

/* Define the structure of the work order complete record */ 
s /* used in the mrp02cp.c program. V 

typedef struct 
( 

10 char wo_no[U]; 

char part_no[17]; 

char qty_asci1[l8]; 

char date_complete[7]; 
75 ) wo_complete_rec; 

/* Define the structure of the work order complete record */ 
/* used 1n the sch02cp,c program. V 

20 

typedef struct 
{ 

char part_no[18]; 
char wo no [12]; 
int qty; 

char date_complete[8] ; 
} wo_compl_s_rec; 

30 
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datagen 



/* 

/* JSource: datagen. c 
/* $Rev1s1on: 1.1 $ 
/* 

/* eiofaal Include */ 

Unclude <std1o.h> 
#1nclude "exOl.h" 

ma1n() 
C 

FILE *wo_fp; 

wo_rec *v/o_ptr, wo buf; 
1nt 1; 

char 1njbuf[80]; 



wo_ptr - &wo_buf ; 

1f( (wo_fp - fopen (MRPWOFILE, "w")) — NULL) 

pr1ntf( "Could not open work order file %s.\n"» MRPWOFILE) ; 
return (0) ; 

} 

for(;;) 
{ 

printf("Do you want to add a new record into the work order flleAn"): 
gets(1n_buf); 
1f (1n_bu^[0] !- 'y') 
break; 

prlntf ("Enter wojio - (up to 10 char)\n"); 
gets(1n_buf); 

stmcpy7wo_ptr->wo_no, in_buf, 10); 
woj>tr->wo_no[113 - NULL;" 
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printf ("Enter quantity ordered \n*); 
gets(injwf) ; 

wo_ptr->qty - atoi (in_buf) ; 

5 

printf ("Enter partjio - (up to 16 char)\n"); 
gets~(1nj>uf); 

strncpy(woj>tr->part_no f 1n_buf, 16); 
70 wo_ptr->part_no[16] - NULL; 

strcpy(woj>tr->duejiate f "891206"); 

1f((1 « fwr1te(*rojtr t sizeof(wo rec), 1, wo^fp) ) I- 1) 

( 

printf ("fwrlte error for %s.\n\ MRPWOFILE); 
return(O) ; 
} 



fc1ose(wo_fp) ; 
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Data Definitions 

DDL is used to da fine data that requires manipulations. 
These definitions are contained in a Data Definition 
(Ddef . def) configuration file. 

Format 

DATA DEFINITION 
""BEGIN 
<declarations> 
END; 

Declarations 

A declaration is a statement specifying the data 
type of one or more identifiers. 

A data type is a collection of elements formed in 
the same vay and treated uniformly. They 
determine these attributes for each identifier: 

- A set of permissible values 

- A set of permissible operations 

- Storage and alignment requirements 

The invention does not bind identifiers to any 
fixed alignment, representation, or language when 
the DDL declarations are compiled. The invention 
binds languages during the link definition 
specification. Alignment and physical 
representation of a structure in memory are 
determined at run time according to the semantics 
and machine architecture when the structure is 
used. 

DDL data types can be: 
— Simple 
— Structured 
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Simple Types 

Simple Data types are pre-defined types that indicate 
the format of the storage for a particular data object. 
The invention supports these predefined simple data 
types: 



Ordinal Boolean char Real User-defined 



BYTE BOOLEAN CHAR REAL OPAQUE 

BIT_FIELD L0NG_BOOL STRING LONG_REAL 

SHORTJENT SHORT_BOOL 
INTEGER 
LONG INT 



Ordinal 

Ordinal types are: byte, bit_field, short_int, integer, 
and long_ int. 

Ordinal types are signed unless they are preceded with 
the keyword UNSIGNED* If ordinals are UNSIGNED, they 
can represent only positive values. 

The unsigned keyword may also change the algorithms 
that the invention uses to calculate alignment, 
storage, representation and type conversion 
requirements. For example, a short. int on an HP9000 
computer may have the values 0 ... .65535. 

Although the actual sizes vary according to the 
machines used, these are the general effects of the 
UNDERSIGNED keyword with type conversions: 

- When the source integer's value is greater than 
can be physically represented by the destination 
type, the destination value will be set to the 
largest number that type can represent. 
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Example: 

A short_int (16 bits) with the value of 346 at the 
source that is converted to a SIGNED byte (8 bits) 
will have the value of 127. If it is converted to an 
UNSIGNED byte, it will have the value of 255, 

~ When the source integer's value is smaller than can 
be physically represented by the destination type, the 
destination integer will be set to the smallest number 
that type can represent. 

Example: 

A short int (16 bits) with the value of -346 at the 
source that is converted to a signed byte (8 bits) 
will have the value of -128. If it is converted to an 
unsigned byte, its value will be 0. 
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BYTE A byte type represents individual characters of data as integers. This type 
is a convenient method for denoting very small integers. It represents the 
crw^iUci individually addressable memory element in 8*bit byte machine 
architectures. The subrange of integers for the byte type on the HP9000 
computers is -128—127. 



BrrjTELD [1-321 
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A bit Jield type denotes an integer that is represented by an arbitrary 
number of bits. Bit fields can extend from 1 through 32 bits* Bit fields can 
be signed or unsigned. The size of an integer on a given architecture is the 
largest bit field allowed Bit fields are placed in storage locations from the 
most significant to the least significant bits. 

Bit fields may not cross or straddle a word boundary as it is defined for a 
particular machine architecture. If a declaration causes a bit field to 
cttH the current word, the bit field is put into the beginning of the next 
word and the remaining bits in the current word are skipped. 
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SHORTJNT Shortjnt, integer, and longjnt types are simple types whose ranges are 
INTEGER determined by subranges of the negative and positive integers. The actual 
LONG INT subranges are determined by the machine architecture on which they are 
referenced. Like other ordinal types, you can modify the subrange with 
the keyword UNSIGNED. On the machine architectures supporting 
these data types, the short Jnt has the smallest width of subranges, and the 
longjnt has the largest For example, these data types have these 
subranges of integers on the HP9000 computers: 

SHORT INT -32,768 . . . 32,767 

INTEGER -2,147,483,648 . . . 2,147,483,647 
LONGJNT -2,147,483,648 . . . 2,147,483,647 

In C on the S300 and S800, integer is the same length as longjnt. 

Note that where an architecture or language does not possess one or .more 
of these data types, the nearest equivalent ordinal type is used instead. 
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Boolean 



SHORT BOOL 
BOOLEAN 
LONG BOOL 



Short Jxx>l, boolean, and long_booI are simple types that in dicate logical 
values! These data types are equivalent to the logical data type in 
FORTRAN. The two possible values for these types are TRUE and 
FALSE. The representation and alignment of a boolean value depends on 
the language and machine on which it is used. 
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CHAR A char type represents individual characters in the 8-bit ASCII character 
sec A character literal is either a single character enclosed by single 
quotation marks or an escape character. All character types are assumed 
to contain ASCII data. Use the byte type if a structure contains binary 
data. The particular character set representation is determined by the 
machine architecture where this data is produced or consumed. 

STRING A string type represents a sequence of characters. The way the character 
sequence is represented depends on the language that produces or 
consumes the data. Strings have an upper Emit of 1024 characters. 

The string type consists of the keyword STRING and an integer 
containing the maximum length of the string enclosed in square brackets. 
For Q the maximum length must include one extra character for the 
terminating null character. For Pascal and FORTRAN, the maximum 
length is the same as would be defined in a Pascal or FORTRAN program. 

In C language, the string type is a sequence of characters terminated by a 
NULL where NULL has a value of zero. The NULL terminator is 
considered part of the string. In FORTRAN, a string type is a sequence 
of characters that is blank-padded to the string's maximum length. In 
Pascal, the string type is a sequence of characters preceded by an ordinal 
specifying the current length of the string. 

Note that the Pascal language on HP9000/S300 and S800 has an explicit 
string data type separate from a packed array of character data type. 
These data types are not the same thing to DDL. Use the DDL string 
type for the Pascal string type. Use the DDL packed array of character 
declaration for Pascal packed array of character data elements. 
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REAL Real and long_reaI types represent a subset of the real numbers. A real 
LONG_REAL type is generally smaller than a long_reaL The range (precision) for this 
data type depends on the machine architecture on which the data is used. 
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User-defined 

OPAQUE An opaque type denotes binary data which the invention should not 
The opaque type is always represented by eight binary bits. The purpose al t er 
of the opaque type is to allow unaltered transfer of binary data between 
different systems. Translating binary data (such as Programmable Logic 
Controller ladder logic programs) to suit a particular machine 
architecture would corrupt the data and prevent its being downloaded to 
its originator. 

Example of Simple Data Type 

This is an example of a data definition using the simple data types BYTE 
and LONGJBOOL: 

DATA DEFINTION 
BEGIN 

Tl - BYTE; 

Stuff - LONG BOOL; 

END; 
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Structured types are built from simple data types or other structured 
types. DDL supports two structured types: 

-ARRAY 

- RECORD 

Pascal structured types may be specified as packed. The PACKED 
specification tefls the DDL compiler that the storage requirements for the 
components of the given array or record have bees or should be 
optimized. The particular storage layout and alignment algorithms 
depend on the language and machine architecture that produces or 
consumes the array or record The PACKED specification has no effect 
on C or FORTRAN elements. 

ARRAY 

An array consists of components that are all the same type. You can use 
other structured types to build structures such as multi-dimensional arrays 
and arrays of records. 

Format 

identifier - [PACKED] ARRAY [ < dimensions > ] OF <type> 
where: 

type Simple types, arrays, records, or other previously defined DDL 

types 

The dimension specification indicates the maximum number of elements 
for a grven dimension of the array. DDL always assumes the lower bound 
of one for each dimension of an array. The dimension length may be any 
integer constant^ You can access each element of an array with the index 
of the array element. 

An array is said to be muIC dimensional if its definition contains more 

than one dimension. The invention defers its assumptions about th 

order of the array element until a specific language is oound to the source storage 

and destination data structures during a data manipulation specification. 

The specific language determines bow the multi-dimensioned arrays are 

stored in memory (row-major or column-major). FORTRAN b 

column-major. C and Pascal are row-major. 
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RECORD 

A record is a sequence of named members that are not necessarily of the 
same type. Each member is called a field of the record and has its own 
identifier. Fields in different records can have identical names but 
represent different objects. You access a Odd is a record with the 
appropriate field selector (".")• 

Fields are placed in physical storage in their order of declaration is the 
record definition. A field's offset is the distance from the start of the 
record to the beginning of the field. 



identifier - [PACKED] RECORD OF[<fields>] 

A field definition consists of an identifier, a colon, and a type. Recursion 
in any form is not allowed. You may not declare a record el ement which 
has itself as the type. 



Example 

This example shows records with members of ample and structured types. 



Format: 



name info - RECORD OF [ 



first 

middle 

last 

]; 



STRING [30] ; 
STRING[30]; 
STRING[30]; 



addrjnfo - RECORD OF [ 



street 
city 
state 
zip 

]; 



STRING[80]; 
STRING[30]; 
STRING[16]; 
INTEGER; 



personal nfo - RECORD OF [ 



name 
addr 
marri ed 
numktds 
kidnames 

]; 



name_info; 
addr_info; 
BOOLEAN; 
BYTE; 

ARRAY [100] OF name info; 
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Language 
Dependencies 



Tabla dl C Data Types and DDL 



HPC 
Type 


DDL 


Comments 


char (ASCII) 


char 


The DDL char data type is always a5srnnrd to contain 
ASCII data, not binary (integer) values. 


char (signed data) 


byte 


The DDL byte type is always assumed to contain an Writ 


unsigned char 


unsigned byte 


binary (integer) value and may be signed or mwigrwi 


short 


short int 




unsigned short 


unsigned short Jnt 




int 


integer 




. unsigned int 


unsigned integer 




long 


longjat 




unsigned long 


unsigned Iong_int 




float 


real 




double 


long_real 




char array 


stringfn] 


For transformation purposes, the DDL string type is 
always assumed to contain ASCH data. 


array 


array 


For the S300 and the S800, arrays are aligned by element 

type. 


struct 


record 


These are the alignment rules for records: 
S300 - nested record - 2 bytes 
S300 * unnested record - 4 bytes 
S800- largest field 


char (as boolean) 


short bool 


Boolean types contain one of only two values: TRUE or 


int (as boolean) 


long_bool 


FALSE. When a DDL boolean type is used, : the invent 
applies the C language-imposed rules for determining if 
the value is true or false. 


short (as boolean) 


boolean 


long (as boolean) 


long_bool 




enum 


integer 





(Table continues on next page) 



45 



50 



55 



74 



BNSDOCI0:<EP 0456249A2> 



EP 0 456 249 A2 



(Continued from previous page) 



HPC 

Type 


DDL 
Type 


Comments 


bit fields 


bitjieid 


C supports a bit field data type. DDL does not explicitly 
support this data type at present. DDL does rapport an 
idealized bit field type with the following assumptions: 

Within a record, a bit Jieid's size remains what it is; it is 
not assummed to be rounded up to any byte boundary. Its 
alignment is considered to be 1 biL 

Within an array, a bit .field's size is assumed to be 
rounded up to the nearest 8, Id, or 32 bits. Its ifignmmt is 
assumed to match this roundeoVup size. 



There is no language counterpart for the DDL opaque data type. T "€ 
indention will not perform transformations on this type Its representation 
is always an unsigned 8-bit octet. An opaque data type is assumed to 
begin at the next byte boundary. 



T&ble C2 shows the DDL equivalents for FORTRAN 77 data types- 



TablaS-Z FORTRAN 77 Data Types and DDL 



FORTRAN 77 
Type- 


DDL 
Type 


Comments 


Logical*! 


boolean 




Logical* 4 


long_bool 




Integer'2 


short int 




Integers 


integer 




Integer*4 






Real*4 


real 




Real*8 


Iong_real 




Character* N 


striog{n) 


For transformation purposes, the DDL string type is 
always assumed to contain ASCII data. 


Array 


array 


For the S300 and S800, arrays are aligned by element type. 


Common Blocks 
Equivalenced data 


record 


These are the alignment rules for records: 
S300 - first field 
S800 - first field 
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Table C-3> shows the DDL equivalents for Pascal data types. 



Table <>3 Pitcal Data Types and 00L 



Pascal 



Boolean 



Boolean 



70 



Boolean 



-128 1?7 



Shoctint 



75 



Integer 



ImegCT 



Char 



20 



int subrange 



int subrange 



25 



30 



35 



40 



Real 



Longreal 



DDL 
1>pe 



short bool 



boolean 



long_booi 



byte 



short int 



integer 



tong^tnt 



bit field 



iinsignrri bi£_Seld 



real 



longreal 



Comments 



Boolean types contain one of only two values: TRUE or 
FALSE. When a DDL boolean type is used, * the ijivention 
applies the Pascal language-imposed rules for determining 
if the value is true or false. 



The DDL byte type is always assumed to contain an 8-bit 
binary (integer) value and may be signed or unsigned 



There is no Pascal shorthtt type on the S30Q. S30G int 
subrange is -32768 — 32767. 



There g no Pascal longjnt type on the S800. 



The char type b always assumed to contain ASCII data, 
not binary (integer) values* 



invent ion 



Bit fields may be from 1 to 32 bits in length. The 
uses Pascal's rules for aligning and sizing bit fields. Sizing 
and afignmmr rules for bets Gelds are shown below. 

Independent bit fields or those contained in an unpacked 
record or arrays 

S300 • Size is rounded up to the nearest 16 or 32 bits; 
aligmnmr is the same as the resulting size. 
SSOO - Size is rounded up to the nearest 8, 16, or 32 bits; 
alignment is the same as the resulting size, 

Bit fields that are elements in a packed array: 
S300 • Size and alignment are rounded to the nearest 1, 2, 
4, 8, or 16 bits. If the bit field is greater than 16 bits in size, 
alignment is 16 bus and size is rounded up to 32 bits. 
S80Q - Size and alignment are rounded up to the nearest 1, 
2, 4, 8, 16, or 32 bits. 

Bit fields that are elements in a packed record: 

5300 - Size is the actual size of the bit field and alignment 

islbiL 

S800 • Size is the actual size of the bit field and allgnn^n i 
is 1 bit 



(Table continues on next page) 
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(Continued from previous page) 



Pascal 

Type 


DDL 
Type 


Comments 


String(N) 


stringfn] 


For transformation purposes, the string type is always 
assumed to contain ASCII data 


Array 


array 


These are the alignment rules for arrays: 
S300 - nested array - 2 byte* 
S300 - unnested array - 2 or 4 bytes 

(2 if the element size is 2 bytes or less) 
S800- arrays are aligned by element type 


Record 


record 


Ttt»«4» 9M ft*^ alitrnffient rules for records* 
S300 - nested record and packed - 2 
S300 - nested record and unpacked - 1 or 2 

(1 if record si2e ts 1 byte or less) 
- unnesteo re core via p»»ew w* -r 

(2 if record size is 2 bytes or less) 
S3G0- unnested record and unpacked -3, 2, or 4 . 

(X if record size is Ibyte or less, 2 if record 

size is 2 or less) 
S800- largest field 


SETS 




DDL does not support enumerated types or sets. 
However, since Pascal represents these types as an ordinal 
type, you can use DDL to define a reasonable facsimile. 
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Example 

This is an example of a string as defined in DDL, C, FORTRAN, and 
Pascal. 



DDL 



Reel -RECORD OF [ 
bl : BYTE; 
si : SHORT INT; 
a3 : ARRAYT3]0FCHAR; 
11 : INTEGER; 

]; 



20 

c 



struct { 

char bl; 

short si; 

char al[3]; 

1nt 11; 
}recl; 
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FORTRAN 



c 


El eraents of structure 




CHARACTER* 1 bl 




CHARACTER*3 al 




INTEGER*2 si 




INTEGER*4 11 


c 


Use this to be sure tnat xne nrst element ot me 


c 


structure is on a 4-byte al ignment 




INTEGER*4 dl 


c 


Call SAR with this buffer 




CHARACTER*30 cbl 




EQUIVALENCE (dl, bl.cbl) 




COMMON /reel/ b, si, al, il 


Pascal 



trecla-RECORO 
bl : char; 
si : shortint; 

al : packed array[l.. .3] of char; 

11 : Integer; 

END; 

buff : array [1.. 200] of char; 

{call SAR using buf } 

treel - RECORD CASE INTEGER OF 
1 : (rl : trecla); 
2: (buf : buff); 
END; 



so 



79 



EP 0 456 249 A2 



Data Definition Declarations 



< data~def -section > 

< declarations > 

< declaration > 
<type> 

< simple-type > 

< ordinals > 



< non-ordinals > 



< structured > 



DATA_DEFINITION BEGIN < declarations s END 

z m < declaration > 

| < declarations s < declarations 

<identifier> » <<>pe> ; 

s» /PACKED/ < structured > 

| <ampte-ope> 

| /PACKED/ < identifiers 

r « /UNSIGNED/ < ordinals > 

| <non-ordinalss 

s« SHORTJNT 

| INTEGER 

| LONG INT 

| BYTE 

| BITJFTELD [ <bit4engths ] 

r- SHORT BOOL 

| BOOLEAN 

| LONG BOOL 

1 CHAR 

| REAL 

[ OPAQUE 

I LONG REAL 

I STRING [ < lengths ] 

ARRAY [ <d£meanw>l OF < types 

| RECORD OF [ <fieldss ] 



< fields > r« < fields ; 

I < fields s <fields ; 

< field > s» ^identifiers : <0pe> 

< dimensions > < lengths 

I < dimensions > , < length > 

<length> z« <dedmal^consts 

<bk-lcngth> 1 1 2 | — | 32 
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APPENDIX D 



Data Manipulations 

After the data structures to be passed between 
applications in DDL, are defined, the Data Manipulation 
- Language should be used to define the manipulation , the 
invention must perform on the structures* These 
manipulations are defined in the Data Manipulation 
Definition configuration file (Dman.def ) . They 
reference the data definitions defined in the Data 
Definition configuration file (Ddef.def). 

DML has two declaration parts: 

- The header section 

• The manipulation statements section 
FORMAT 

DEFINE MANIPULATION <identif ier>; 
SOURC£~DATA: <identifier> 
DESTINATION^ data : <IDENTIFIER> : 

BEGIN MANIPULATION 
<manipulation statements> ; 
END_MANIFULATION ; ' 

Header Section The header section defines: 

• The name of the manipulation 

- The* name of the DDL definition of the 
source data 

- The name of the DDL definition of the 
destination data 

Manipulation Statements Section 

The manipulation statement section contains the 
instructions for translating from one data structure 
format to another. The instructions or statements are 
executed sequentially in their order in this section. 

There are two kinds of statements in the declaration 
section: 

-Assignment statements 
-Move statements 
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Assignment Statement Assignment statements assign literal values and operators for accessing 

arrays and structures. 



Format 

structure * value; 



You use assignment statements primarily to set a default value (constant 
or literal) for a destination Held 

10 The literal value assigned to the destination field may reference only the 

destination DDL data type which must be a simple type or an array of 
simple type. If the destination Held is an unqualified array* the literal 
value specified sets all the elements of the array. 

75 The literal value must be appropriate for the destination Held type. For 

example, a destination field that is an integer type must be assigned a 
literal that is an integer* The literal value must also physically fit within 
the legal range of values for the destination type. For example, a signed 
byte as the destination type must be assigned a value between -128 and 
127. Any other value is illegal. 



Constants 



Constants are primary expressions whose Hteral or symbolic values do not 
change. Each constant has a value and a type determined from its form. 3fte 
indention jrvaluates constants at compile time. 

Constants can have these values: floating point, integer* changer, and 
string literal. 

Floating-point constants represent floating-point values. They consist of a 
coe ffi ci en t and an optional scale factor (exponent). The coefficient is a ' 
decimal point with at least one digit preceding or following it. The 
optional exponent is introduced by either the £ (or e) character or the L 
(or 1) character (for an extended floating point number) followed by the 
scale factor. Maximum and minimum values and significant digits deoend 
on the particular machine architecture used. 



30 

Floating-Point 



35 



40 

These are examples of floating-point constants: 

3.14159265358 J1459e + 1 7.E5 

S76 Z 

45 

Integer 



so 
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/ Integer constants represent imeger values. This constant consists of a 
sequence of digits with an optional preceding sign character. 

Use the L suffix to force a constant to a long integer (cample; 37L or 
371). Begin hexadecimal constants with Ox (the x character case does not 
affect its value). You can force hexadecimal constants to long integers 
with the L suffix. Examples of hexadecimal constants are: 



OxAAF 



OxbAd 



OX1AF7L 



Character Character constants are any characters except the single quote ('), the 

double quote (*), and the backslash (\). Use the backslash character (\) 
followed by up to three octal digits for octal escape sequences. Note that 
this octal representation docs not require a leading zero and you can use 
fewer than three digits. The two character constants below are identical; 
each represents the decimal value of 68: 



and 



f \104* 



Use the backslash character followed by an x and up to two hexadecimal 
digits for hexadecimal escape sequences. The two character constants 
below are identical: 

•C and *\x43* 

In both octal and hexadecimal representations, the backslash and 
following digits are converted into a single 8-bit character which is stored 
in the character constant. 

The escape sequence representation of new line, single quote, backslash, 
and double quote special characters are \n, \\ \\, and \* respectively. 



String Literal A string literal constant is a sequence of zero or more characters enclosed 
in double quotation marks ( * and * )♦ 



Use the escape character 
sequence to represent the double quote character appearing in a string 
literal as in the example below. 

• Samantha said \"Shorten the sentence\* • 

Consecutive double quotation marks represent null strings. 

Note that you cannot escape the escape character itself. You must 
represent it as a hexadecimal or octal constant (example: \xSc) 

The invention determines the type and representation of the string by the 

context in which it is used and stores it correctly for its given language and 
machine architecture. 
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IS 



20 



Move Statements Move statements let you move a source structure into a destination 

structure with a transparent correction for language and machine 
architecture incompatibilities. The move statement performs these tasks: 

- Corrects for differences in the languages of the source and des- 
tination structures 

* Corrects for differences between the architectures that 

produce the source and consume the destination structures 

- Provides type conversions between the structure components 
where necessary. 

Format 

MOVE < sources TO <dest> [USING •<fi«t-<Iescr>T 

The move statement consists of the keyword MOVE, the data source 
structure, the keyword TO, and the data destination s tru ct u re. Use the 
optional keyword USING followed by a format descriptor to convert 
between numeric and ASCII structure components. 



Source and dest refers to the name of any structured type or any ffrmfnt 
(field) of a structured type. The source and destination structures are 
25 de fi ned with DDL in the Ddef.def file and specified in the header section 

of the data manipulation definition. Note that destination to destination 
moves and source to source moves are not allowed. 
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Array Subscripting 

AH elements of the array will be moved if the array is not subscripted. 
You can make a subscripted reference to a single element in an array. 

DML uses the language declared in LinLdef to determine the storage 
method of the individual elements of an array. Both C and Pascal store 
their array elements in row-major order. This is the opposite of 
FORTRAN which stores array elements in column-major order. The 
Link Definition file (Link.def) lets you select C, Pascal, or FORTRAN as 
the language that determines the storage of multi-dimensional arrays in 
the source and destination DDL data definitions. 

Structure Members 

You can move the enure structure by specifying an unqualified structure 
name. You can move a subset of the structure by using the field selector 
operator (.) to qualify the structure. 

This is the convention that the move statement uses to determine which 
50 source structure components are moved into which destination structure 

components: it converts any component (field) in the source structure 
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that has a name identical to a destination structure component (field) to 
the appropriate destination component type and then moves ic This 
definition can be applied in a nested fashion, that is, the components of 
structured components also follow the same rules. 

The move statement ignores component names resting in the source but 
not the destination structure. The move statement i ni ti a lirat component 
names existing in the destination but not the source structure to default 
values appropriate for the type. 



75 
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30 



name infol - RECORD OF [ 
first 
last 
middle 
ssn 

]; 

name info2 - RECORD OF { 
last 
middle 
first 
ssn 

]; 



Example 

These are DDL definitions for source and destination data structures. 

stringflS]; 
string[30]; 
string[15]; 
array[9] OF char; 



string[30]; 
char; 

string [20]; 
1 ong_i nt ; 



misc struct « 



35 



RECORD OF [ 

rdata : real ; 
idata : integer; 

]! 
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source - RECORD OF [ 

rec_size 

descript 

recjlata 

com struct 

differentl 

1; 

destn - RECORD OF [ 

rec_type 

rec_size 

rec_data 

construct 

different2 

]; 



: short int; 
: STRING[30]; 

: array[10,5] OF integer; 
: misc_struct; 
: name_infol; 



: char; 
: long_int; 

: array[10,8] OF STRING[20]; 
: misc_struct; 
: name_info2; 
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These are examples of DML move statements moving the source data to 
the destination data defined above. 

HOVE source TO destn; 

HOVE source. differentl TO destn. different2; 

MOVE source. construct. rdata TO destn. com_struct.idata; 

MOVE source -descript TO destn. rec_data[l f 8] ; 

Figure Dl shows what happens when you move source to destn. 



15 



20 



25 



artl22 



MOVE source TO destn; 
source destn 



rec_size ■ 
desenpt 
r ftc_data ■ 
com_struct.rdata • 
com_struct.idata ■ 
diff«r«nttttfst 
differenttlast 
differentljniddle 
differ entlssn 



rec_type 
rec.size 
rec^data 
• com.stnjcudata 
•com_strucUdata 
different2Jast 
differentZmidcfle 
diffsrent2.first 
differ en t2.ssn 
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Figure Dl Move Statement Example 1 
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Fia. 02 -hows what happens when you move the field sourer, HifTercntl 
to the destination field destn.duTerentZ. 



w 



15 



art123 



MOVE source,different1 TO destn.different2; 
source destn 



20 



rec^size 
descriot 
rec__data 
com_structj'data 
cam_struet.idata 
differantl-first 
diffarentLIast 
differenttmiddie 
differenttssn — 



rec_type 
fee. size 
rec_data 
com_strucUdata 
com_$truct.idata 

• cfif ferent2.1ast 
different2.midd!e 

• dif fef«nt2.first 
. differ en t2.ssn 
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Fig. D2 Move Statement Example 2 

Fig.D3 'shows what happens when you move the com_structxdaia field 
in the source structure to the com_struct idata field in the destination 
structure. 
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MOVE source.com_struct.rdata TO destn.com_struct.idata; 
source destn 
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r«c_$iz* 

descript 

f«c_data 

com — 5truct.fdat8 

com_structJdata 

ditferenttfirst 

diffcrtfitttast 

dirferentljmddto 

diff«r«nt1.ssn 



rec_type 
rec_$iz» 
rec_data 
com M stmct/da(a 
- com_strucuaata 
differtnt2Jast 
differ<nt2.nvdd)e 
differtntZftrst 
differ en t2Lssn 



Fig. D3 Move Statement Example 3 
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1 



. For ecimpleyihe move 

statement bandies type conversions between fields with different numeric 
types and between ASCII and numeric types. 

Refer to the following tables for the rules for these data type conversions: 
* Boolean (boolean to boolean, ordinal to boolean) 

- Numeric to numeric 

- Floating point (integer to floating point and floating point to in- 
teger) 

- ASCII to numeric and numeric to ASCII 
Boolean Typo Table D-4 shows tne action for boolean type conversions* 

Conversions 



Ta ble D-4 Boolean Type Conversions 



25 


Source Field Tjrpe 


Destination Field 
Type 


Action 




Short boolean 


Boolean 


If the source field type is a boolean, the destination Geld 




Boolean 




type must be a boolean. 


30 


Long boolean 




35 


Integer 


Boolean 


The source field type language determines whether the 
integer type is true or false.- For example, if the source 
language is Pascal, a zero value means FALSE is placed into 
the destination field; a value of one places TRUE in the 
destination field. Any other value yields an unpredictable 
destination field value with a warning logged at the source 
node. If (he source language is Q a value of zero is FALSE 
and a non-zero is TRUE. 



40 



D ML Type 
Conversions 



TO 
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Numeric to Numeric 
Type Conversions 



Numeric to numeric type conversions involve handling the differences in 
the sizes and the signs of the source and destination data fields. 

Table D-5 shows tte rules in converting from one numeric 
type to another numeric type. 



Numeric Type 


Source/Destination Size Difference 


HP Sockets Action 


Integer 


The value of the source is larger than the 
destination can hold 


HP Sockets sets the destination to the 
maximum value the destination can hold. 

Example: If an unsigned byte holding 250 
is moved to a (signed) byte, HP Sockets 
sets the value in the byte to +127. 




The value of the source is smaller than 
the destination can hold 


HP Sockets sets the destination to the . 
minimum value the destination can hold. 

Example: If a (signed) byte holding -46 is 
moved to an unsigned byte, HP Sockets 
sets the value in the mwipmrt byte to 0. 


Floating point 


The source's value is too large to be 
represented in the destination (overflow) 


HP Sockets sets the destination to the 
maximum value the destination can hold 

Example: If the source is a iong_real with 
a value of 63E+50 and it is moved to a 
real (on the S300), HP Sockets sets the 
destination to 3.402_E+38 because that 
long_real value cannot be represented in 
a (S300) real 




The source's value is too small to be 
represented in the destination (underflow) 


HP Sockets sets the destination to zero. 

Example: If the source is a loog_real with 
a value of *1E*300 and it is moved to a 
real, HP Sockets sets the destination toO 
because cannot be represented in 
area!. 
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These are the general rules for conversions between numeric types 
(integer and floating point) : 

• If the value of the source Held is greater than can be represented 
physically by the destination, the destination is set to the maTimnm 
permissible value (infinity if supported by the architecture). A run 
time warning is generated and logged. 

• If the value of the source is smaller than can be represented 
physically by the destination, the destination is set to the minimum 
permissible value (negative infinity if supported by the architecture). 
A run time warning is generated and logged. 

T^ h! f» D-6 ' demonstrates the rules for integer to floating point and floating 
point to integer type conversions. 



tohle D-6 "Floating Point to Floating Point Type Conversions 



Source Field 1>pe 


Destination Held l>pe 


MP Sockets Action 


Integer 


Floating potiu> 


If the integer's precision is greater than a real cype can 
represent, the least significant digits are lost 


Floating point 


Integer 


HP Sockets truncates the fractional part 



Floating Point Type 
Conversions 
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ASCII and Numeric You can convert a numeric type to ASCII and the reverse if one of the 
Tvn<» Pfi mmrslons fields is a string or char type and the other is in integer or floating point 
iype uynvci«iwua ^ XaWe ^7 s^ws these conversions. 



Table I>7 ASCII and Numeric Type Conversions 



70 


Source Field Type 


Destination Field Type 


Action 




Numeric: 

Integer or 
floating point 


ASCII: 

String or 
char array 


Source value is convened to an ASCII format generic to the 
numeric type* If the destination field is not large enough to 
bold the ASCII data, asterisks (*) are put into the field. 


75 


Numeric: 

Integer or 
floating point 


ASCII: 

Multi- 
dimensioned 
array of char 


The number's ASCII representation is placed into each row 
or column of the destination array according the destination 
language. That is, the array is filled by rows if the 
destination language is C or Pascal, and filled by columns if 
it is FORTRAN. 


20 






If the source field is an array, each dement of the source 
array is 1) processed in row-major order for C and Pascal 
and column-major order for FORTRAN, 2) type converted 
to ASCII, and 3) its ASCII representation placed in the 
appropriate row or column of the destination array. 


25 
30 


ASCII: 

String or 
char array 
(Only decimal, octal, 
hexadecimal, or sign 
characters allowed For 
floating point E, e, and 
dot (.) allowed.) 


Numeric: 

Integer or 
floating point 


Source value is converted to numeric type. If the 
destination field cannot contain the numeric value, the max 
or min values are used depending on the value of the source 
field. 


35 
40 


ASCII: 

Multi- 
dimensioned 
array of char 
(OnJy decimal, octal, 
hexadecimal, or sign 
characters allowed. For 
floating point E, e, and 
dot (.) allowed.) 


Numeric: 

Integer or 
floating point 


The number represented in ASCII in the source is placed 
into each row or column of the destination array according 
to the destination language. That is, the array is filled by 
rows if the destination language is C or Pascal, and filled by 
columns if it is FORTRAN. 

If the source field is an array, each element of the source 
array is 1) processed in row-major order for C and Pascal 
and column-major order for FORTRAN, 2) type converted 
to numeric, and 3) the number is placed in the appropriate 
row or column of the destination array. 




ascii 


Numeric array 


Each element of the array is set to the ASCII value. 
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Example 

This is an example of numeric to ASCII type conversions. This example 
shows moving the date consisting of three integers into an ASCII string 
and an ASCII array of char. 

This structure in a C program contains information about an operator that 
includes the date employment started: 

struct { 

char 0perator[20]; 

1nt Month; 

int Day; 

int Year; 
} id, rid; 

The manipulation that we want to do is to move the operator and date 
information into both of these 2 structs: 

struct { 

char 0perator[15]; 

char Date[ll]; 
} rl, rrl; 

struct ( 

char 0perator[15]; 

char 0ate[20J; 
} rla, rrla; 

These are numeric to ASCII conversions, moving integers from structure 
id into a character string (in structure rl) and an array of char (structure 
rla). 

These are the DDL data definitions for the three structures: 

DATA DEFINITION 
BEGIN 



/* Define structure ID as a record named 
tnputjiata 1n DDL */ 



1nput_data - RECORD OF [ 
Operator 
Month 
Day 
Year 



STRING[20]; 
INTEGER; 
INTEGER; 
INTEGER; 
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]; 

/* Define structure id as a record named reportl 
in DDL */ 



reportl - RECORD OF [ 
Operator 
Month 
SI ashl 
Day 

S1ash2 
Year 

]; 



STRING[15]; 
ARRAY [2] OF CHAR; 
CHAR; 

ARRAY [2] OF CHAR; 
CHAR; 

STRING[5]; 



/* Define structure rla as a record named 
reportla in DDL */ 



reportla - RECORO OF [ 
Operator 
Year 
Ootl 
Month 
Dot2 
Day 

1; 

END; 



ARRAY[15] OF CHAR; 
ARRAY [4] OF CHAR; 
CHAR; 

ARRAY [2] OF CHAR; 
CHAR; 

STRING[3]; 



i_to_reportl is the manipulation definition for moving the input data 
structure into the reportl structure. This displays the operator name as a 
string, and the date in American format (mm/dd/yy). It uses the 
assignment statement to set the characters Slashl and SIash2 to V. 

DEF I NEWMAN I PULAT I ON i_to_reportl ; 
SourceJData : inputjiata; 
Destination_Data : reportl; 

Begin_Manipulation 

move input jiata to report i; 
reportl .Slashl - '/'; 
reportl. SI ash2 • '/'; 



End_Mam* pul at i on ; 
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i_to_reportla is the manipulation definition for moving the input data 
structure into the reportla structure. This displays the operator's name as 
an array of char, and the date in European format (yyjnm.dd). It uses the 
assignment statement to set the characters Dotl and Dot2 to V. 

OEFINE_MANIPULATION i_to_reportla; 
Source J)ata : inputjlata; 
Destination_Data : reportla; 

Beg 1 n_Man i pul at 1 on 

move inputjlata to reportla; 
75 reportla. Dotl - 

report la. Do tZ « '•'; 
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Endjianipulation; 
If structure id is initialized to these values: 

strcpy( id. Operator, "John Skupniewicz") ; 
id.Month - 1; 
id. Day » 30; 
id.Year - 1990; 

The converted structure will display in Reportl as: 

Operator is John Skupniewi 
Date is 1 /30/1990 

and in Reportla as: 

Operator is John Skupniewi c 
Date is 1990.1 .30 
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ASCII Format You can control the format of ASCII values by means of a format 

descriptor specified with the move statement. The format descriptor 
controls type conversions at cither the source or the destination. When 
5 the ASCII data is the source field, the format descriptor describes the way 

the source data is read. When the ASCII data is the destination, it 
describes the way it should be generated* 

Format ASCII values with the keyword USING followed by a format 
10 descriptor as in this example: 

MOVE <source> TO <dest> [USING w <fmt-descr>"] 

Refer to the Move Statement description for explanation of the 
75 components in the move statement. 

Valid formats are: 
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%d Decimal integer (signed or unsigned) 

%u Unsigned decimal integer 

%o Octal integer (signed or unsigned) 

%x Hexadecimal integer (signed or unsigned) 

%[mjs]f Floating point number in the form [-jmLfTIF 

%[mn]e Floating point number in the form [-j JHnTe[-]xx 

where: 

m Designates the field width in characters including 

any signs or decimal point 
n Designates the precision 

m must be greater than n. 

m and n are optional. If they are not specified* m has a default of 
14 and n has a default of 6. If the destination field cannot hold a 14- 
character width, the width is decreased starting with the digits to the 
right of the decimal and continuing to the digits to the left of the 
decimal if necessary. A warning message is issued. " 

Example 

This is an example of using a MOVE statement to convert a buffer 
from a real type to an ASCII type using a real number format descrip- 
tor 

MOVE bufferl.real TO buffer2.asc11 USING '%I6.2f" 
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Table D-7 describes results of other actions in formatting ASCII data. 
Tabic D-7 Formatting ASCII Data 



Action/Condition 


Result 


Source data does not match the format specified 


No conversion performed. Warning message is yritifi 


Format descriptor left out of the MOVE 


Default formats used: 

%d for ASCII to ordinal and ordinal to ASCII 
%14.6f for ASCII to real or real to ASCII 
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la addition to type conversion, the move statement also resolves the 
differences in tie way different languages represent simple and structured 
types. For example, while the C language represents FALSE as any zero 
value and TRUE as any non-zero value, HP Pascal represents FALSE as 
zero and TRUE as one in the rightmost bit of a byte. 

When both the source and destination Gelds arc boolean^ MOVE 
converts data as appropriate for the language bound to the data structure 
in the source and destination specification section of this data 
manipulation definition. 

MOVE corrects for any difference in the order the elements of 
multi-dimensional arrays are stored. It uses one of two storage m et h ods 
row-major or column-major. In column-major storage, the first dimension 
of the array varies most rap ; dly in terms of the sequence of elements 
Stored in memory. In row-major order, the last dimension of the array 
varies most rapidly. 

When the source is a raulti-dimensional array, DML examines the 
language of the destination field for its storage method. If the arrays use 
different storage methods, the move statement converts the source array 
to the method used by the destination field's language, It moves the 
converted source array into the destination field up to the maximum 
number of elements in the source or the destination array, whichever is 
first. The source array is truncated if it is longer than the destination field. 
If the source is smaller than the destination, remaining bytes in the 
destination are not touched. Uninitialized destination array elements are 
set to default values. 

The number and size of elements in the source and destination arrays do 
not need to agree for proper conversion. DML accesses the source array 
element by element according to the language bound to it The 
destination array is filled according to the row-major or column-major 
rules of its language. The following example in which the source(sarray) is 
in FORTRAN and the destination (darray) in C shows this conversion. 

Example 

At the source, sarray is stored in memory in this order 

s a rray [ 1 , 1 ] s array [ 2 , 1 ] 
sarray [1,2] s array [2,2] 
sarray [ 1 , 3 ] sarray [2 1 3 J 

At the destination, darray is stored in memory in this order 



Language 
Specifics in the 
Move Statement 
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darray[l,l] darray[l t 2] darray[l,3] 
darray[2,l] darray[2,2] darray[2,3] 

5 You made these DDL and OML declarations: 

sarray • ARRAY[2, 3] OF BYTE; 
darray - ARRAY [2, 3] OF BYTE; 

10 

MOVE sarray TO darray; 
This would be the result of the MOVE : 

,s darray[l,l] - sarray[l,l]; 

darray[l,2] - sarray[l,2]; 

darray[l,3] « sarray[l,3); 

darray [2,1] « sarray[2,l]; 
so darray(2,2] « sarray[2,2]; 

darray[2,3] « sarray[2,3]; 

Declare both the source and destination as one-dimensional arrays to 
2g place the source array elements into a destination array while retaining the 

source array in its original memory order. 

MOVE takes care of any alignment di (Terences induced by language or 
architecture, 
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Data Manipulation Language Syntax 



TO 
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< maaip-def-scction > n- 

< main-body > n» 
<sourcc-spec> 
<dest-spec> r — 

< statement-sect > z« 

< statement > r- 

I 

< statement > r« 

I 

< xlation-statement > s - 

< move-statement > s •» 

< expression-statement > n — 

i 

< postfix-expression > = — 

I 

! 

< primary-expression > z ^ 

I 

I 

<mu-descr> 



45 



<reai-descr> 
<width-len> 
< digit-len > 



DEJTINE_MANIPULATION <idaitifier> ; < main-body > 
<source~spec> <dest*spee> < statement-sect > 
SOURCEJDATA: ^identifiers ; 
DESTINATION.DATA: <identiper> ; 

BEGIN.MANIPULATION <suaemems> END^MANIPULATION ; 

<statements ; 
<statementss < statement > 

< expression-statement > 

< Tiation-staiement s 

<rnove-statements 

MOVE < postfix-expression > TO < postfix-expressions 
/USING • <mu-descr> 7 

< postfix-expression > = < constants 

< postfix-expression > = <stnng*GteraI> 

< primary-expression > 

< postfix-expression > [ < primary-expressions ] 
< postfix-expression > . < identifier > 

<idendfer> 

< constants 
<suing-constant > 

« 

%x 

*u 

<reaJ-descrs Jt 
< reai-descr > ]e 

< widthAen > . < digit-fen > 

< decimal-const > 

< decimal-const > 
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Lexical Elements 



< token > 



< identifier > s 1 

I 
I 

< nondigit > n> 

< digit > r> 

< constant > .= « 

I 
I 
I 

< floaling-pt-const > r 1 

I 

< fraction-const > n* 

i 

<exp-part> • r« 

I 

< digit-sequence > 

I 

<sign> 

< integer-const > 

I 

< decimal-const > S' 

i 

< hexadecimal-const > si 

i 



< identifier > 
<constanf> 

< operators 

< punctuation > 

<;uvuii£if > 

< identifier > < nondigit > 
<identjfier> <dipt> 

any character from the sec _ [a_x] [A_Z] 

0!l| — I9 

<floaring-pt-const'> 

< integer-const > 

< character-const > 
<string-4itcral > 

[<sipt>] <Jraaion<onst> {<expi*rt>] 
[<siff%>] < dipt-scquencc > <ap*part> 

[< digit-sequence >] . < digit-sequence > 

< digit-sequence > . 

E [<sipi > J < digit-sequence > 
L[<sign>] < digit-sequence > 

«ffgif> 

< digit-sequence > < digit > 
+ I- 

[<sipx>] <dccimal<onstant> [<suffix>] 
[<sipi > / < herndrarnai-constant > [<> suffix > ] 

<noazero-digit> 
<dedmai<onstant> < digit > 

OX <hex-digit> 

< hexadecimal-constant > <hcx~digif> 



< nonzero-digit > 



l|2|-l» 
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< hex-digit > 

< suffix > 

< character-coast > 
<c-char> 

< escaped-character> z * 

< string-literal > z ' 

< s-char-sequence > 

<s-char> 

< operator > 

< punctuator > 



n =« any character from the set: 
0123456789 
ibcdef 
A £ C D E F 

!|L 

~» f <c<har> f 

any character except 9 or \\ 
| <cscapcd-character> 

V \* \n \ddd \xdd 

z « ' • / < s-char-sequence >J m 

| <s<har~sequatc£> <s<har> 

s« any character except * \\ or \n 
| <esaxpcd<haTacter> 

z — One selected from the sec 
[ ] • « - 

:■ One selected from the sec 
E 1 : ; 
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APPENDIX E 

Pseudocode 



75 
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header joj:dr{ ) 
Check If argueents passed in are Legal. 

If cdr version nusbers ere not compatible 

Error 
Endif 

Set up globe I variables with values passed into this routine-* 
target Jauffer pointer, octets available count, target language. 

Initialize global vers for type attribute start and length, and 
total target buffer length used. 

If a flag Indicating whether the tratler_tq_cdrO call hasn't been done 
prior to this call 

Error ctwo heeder_to_edrO calls were done without an intervening 
trailer_to_cdr(> call") 
/* this is an "error* aa opposed to a •warning* coupled with 
a call to trailer_to_edrO since we can't tail If the current 
target jatr buffer is e new one or the old one that didn't 
use a trailer_to_cdr() call. So we'll just flag it as an 
error. */ 

Endif 

35 If the target Jxrffer pointer Is HULL 

Error 
Endif 

If target language is invalid 
40 Error 
Endif 

It the sUe of the targat_buf fer cannot contain the data buffer header 
Error 

45 Endif 

/* Assign values to the data buffer header in target_buff er-* */ 
/* "Hend-e*r*hall» means you oust do it directly without the •/ 
/* Sid of an ASH. 1 routine. •/ 



30 
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Hand-marshal I version control id and target lang into the t*rget_buf fer. 
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If not okay 

Error 
Endif 

Hand -march a 1 1 reservation space far a 4-byte ASM.1 integer for tha type 
attribute atart. f MOTE: thia ia a non-standard ASM.1 integer */ 

If not okay " /* will fill in thia value after awrshaUing is complete */ 
Error 

Endif 

Hand-marshall reserve t ion space for e 4 -byte ASM.1 integer for the 

type attribute length. /* MOTE: thia is a non-standard ASM.1 integer V 

If not okay /* vill fill in thia value after marshalling is complete V 
Error 

Endif 

Hand-sttrshell the type/length octets of an octetstring into the temp_buffer 

to atart the ASM.1 fonnat for the type attributes. 
Set laat_itea - not_string. 

Allocate a default stack fraste for array_stack. 

Set top_of_stack fielda to rae_eount « 0; initial ready • no 

/ trailer jtojcdff) 

If there ia not enough space In the teap_buffer for thia type attribute 10 
Allocate another temp_buffer and link It into the teap_buffer list 

Endif 

If (currently open octetstring in type attribute* buffer) 

Put end- of -contents octets In type attribute buffer to close off currently 

open octetstring. 
Endif 

Concatenate tens\buffer onto the targetjsuffer by copying oeteta fro* 
the tenp_buffer(s) to the target_buffer. 

Update type_attr a start value in data buffer header with the final value. 
Update type_attr_length value in data buffer header with the final value* 

/* Optional Check: was array_stack was emptied properly? */ 

Return to the caller the total number of octets used for oershailing 
for all routines. 

array jo_cdr() 

If laat_itera uaa string type 

If there is not enough space in the tempjxjffer to restart octetstring 
in type attributes buffer 
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Allocate another ttop^buffer and link it into tha teap_buf far I tat, 
Endif 

Restart typa at tribute* octetstring for tOa. 
Sat laet_itaei « not^etring. 
Endif 

If there ia not enough space in tha te*p_buf fer for thia typa attribute 10 
Allocata another te*p_buffer and link ft into tha teaj>_buffer Mat 

Endlf 

If there ia not enough apace in the target_buf fer for thia ASM.1 data eleaamt 

Error 
End if 

If top w of_etaefc initial ready ■ no 

If compression * PACKED 

Aaeign type attribute value to tespjxrffer. 
Elae if etaapresaion ■ NOME 

Aaeign type attribute value to teapjsuffer. 
Elae 

Error 
Endif 

End if 

Push new frame on arr ey_iteck. 

Initialize new eteck free* field ree_count to 0. 
Initialize new atack fraoe ffeld initial ready to tha init_elreedy 
value of old top~of -stack. 

Aaeign ASM.1 data eleaamt to target Jauf fer. 

array^endjioj:dr{ ) 
•op atack freaa* fro* array_stack. 

If top_of_stack rec^count « 0 /* thia wee an array or array of array? */ 

Set initial ready * yea. 
Endif /* elae the array that just ended wee e part of e record end 
the record haen't ended yet V 

If there is not enough space in the target Jxif fer for this ASM.1 data a lean 

Error 
Endif 

Assign ASM.1 data element to target_buf fer. 
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bitJieldjojcdr() 

If source_ptr » MULL 

Error 
Endff 

If start Jaitj»sftfon < 0 or > 31 

Error 
End If 

If nua_ofJ>its < 1 or > 32 

Error 
Endff 

If last J ten mi string type 

If there is not enough space In the tempjxiffer to restart octetstrfng 
in type attributes buffer 

Allocate another testpjaiffer and link ft into the taspjwffer Ifst- 
Else 

Restart type attributes octetstring for IDs* 
Endif 

Set laat_ftem « not_string. 
Endff 

If there is not enough space fn the tenp Jsuffer for this type attribute 10 

Allocate another tenp.buffer and link ft into the tenpjsuffer Ifst 
Endff 

Calculate nuntoer of bytes needed to store bits. 

If there (a not enough spaee in the target_buffer for this ASM.1 data elem 

Error 
Endff 

If top_of_stacfc init^alreaey * no 

If signed * SIGNED 

Assign type attribute value to tempjbuffer. 
Else if signed « UNSIGNED 

Assign type attribute value to tenpjbuffer. 
Else 

Error 
Endif 

If top_of_stacic ree_count « 0 /• for the simple- type srray type */ 

Set imt^already • yes. 
Endff /* else this data element was a part of a record V 
Endff 

Assign ASH.1 data element to targetjxiffer. 
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booljojcdii) 

If sourcejatr » NULL 

Error 
Endif 

If bool_value,o CDR_TRUE and o CDR_FALSE 

Error 
endif 

If last_itoa ue* string type 

If there is not enough space in the teajMsuffer to restart octetstring 
in type attributes buffer 

Allocate another teapjxrf fer end link it into the te*p_buffer list. 
Else 

Restart type attributes octetstring for IOs. 
Endif 

Set laet_itea ■ not_atring. 
Endif 

If there is not enough space in the tespjauffer for this type attribute ID 

Allocate another teopjxrf fer and link it into the teepjbuffer list 
Endif 

If there is not enough space in the tsrgot.buffer for this A5K.1 data ■iaainr 

Error 
Endif 

If top_of_stacfc init.alreaoV ■ no 

If DOL_type - SKORT^BOOLEAH 

Aasign type attribute value to teac^buffer. 
Else if OOL.typo « 800LEAM 

Assign attribute value to teap_buffer. 
Else if 00C_type - LONG.ftOOLEAN 

Assign type attribute value to taap_buffer« 
Else 

Error 
Endif 

If top_of_ stack rec_count ■ 0 

Set initial ready * yes. 
Endif f else this data elei 
Endif 

Assign ASH.1 data • lament to targetjuffer. 



/* for the simple-type srrsy type V 
nt was a part of a record */ 



106 



EP 0 456 249 A2 



charjiojzdri) 

If source_ptr * NULL 

Error 
Endff 

If littjtaruat string type 

If there is not enough space in th« teo^buffer to restart octetatring 
in type attributes buffer 

Allocate another tempjxiffer and link it into the teaojsuffer Hat. 
Elee 

Restart type attributes octetatring for IDs* 
Endif 

Set last_item ■ not^string, 
Endif 

If there is not enough apace in the tenp_buffer for thit type attribute; ID 

Allocate another teiap_buffer and link it into the t«p_buffer list 
Endif 

tf there is not enough space in the targe tjxrffer for this ASN.1 data a lenient 

Error 
Endif 

If toq_pf_ataefc initial ready ■ no 

Aaaign type attribute 10 to tesrp_buffer. 

If top_of_stack rec.count « 0 /* for the simple-type arrey type V 

Set init_alreedy • yes. 
Endif /* else this data element was a part of a record */ 

Endif 

Assign ASH.1 data element to targetjxif far* 

intjoj:dr() 

If eource_ptr ■ HULL 
Error 

If bit_length « 0 

Error 
Endif 

If I as t_ Item was string type 

If there is not enough space in the temp_buffer to restart octetstring 
in type attributes buffer 

Allocate another temp_buffer and link it into the t«p_buffer list. 
Else 
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Restart type attributes octststring for IDs, 
Endlf 

Set last^itea ■ not_strfng. 
Endlf 

If there is not enough space fn the tonp_buffer for this type attribute 10 

Allocate .another teop_bufftr and link it into the tenp_buffer list 
Endlf 

Calculate nunber of bytes needed to store bits. 

If there is not enough space in the tsrget_buffer for this ASM.1 data elaawnt 

Error 
Endlf 

If top_of_stack inft_alreaoy ■ no 

If D0L_type « SYTE 

Assign type attribute value to teap_buffer. 
Else ff D0l_type ■ SHORTJfcT 

Assign attribute value to t«ep_buffer. 
Else if DOL_type m IMTECEX 

Assign type attribute value to teap^buf fer. 
Else if D0L_type * LQNG_tMT 

Assign type attribute value to teapjaiffer. 
Else 

Error 
Endlf 

It top_of_st*clc rec_count • 0 /* for the siepls~type srray type */ 

Set init_alreedy ■ yes. 
Endlf /* else this data element was a part of a record •/ 
End if 

Assign ASM. 1 data eleaent to targst_buffer. 
opaque jioj:dr( ) 



If source_ptr « null 
Error 

40 Endlf 

If nuBjof_octets ■ 0 

Error 
Endlf 



50 



If l as t_ item was string type 

If there Is not enough space in the teap^buffer to restart octetstrlng 
in type attributes buffer 

Allocate another tempjauf fer and link it into the tetrp buffer list. 
Else 
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Restart type attribute* octetstring ior IDs. 
tndif 

Set last_ite» • not_*tring. 
Endif 

If there is not enow space in the teapjxiffer for this type attribute ID 

Allocate another te«p_buffer and link it into the teapjxiffer list 
Endif 

If there is not enough spec* in the target Jjuf f er for this ASM.1 data element 

Error 
Endif 

If top_of_stacfc tnit^elreeoV » no 

Assign type attribute ID to te*p_buff«r. 

If top_of .stack rec_count • 0 /•for the simple-type array type V 

Sat init_already « yes. 
Endif /* else thia data element m a part of a record V 
Endif 

Aesign ASH.1 data element to target_buffer. 

l realjojodri) 

If eource _ptr * MULL 

Error 
Endif 

If bit_length - 0 

Error 
Endif 

tf lestjteai was string type 

If there ia not enough apace in tht tempjjuffer to restart octetstring 
in type attributes buffer 

Allocate another teapjbuf fer and link it into the temp^buffer list. 
Else 

Reatart type attributes octetstring for IDs. 
Endif 

Set last_item « not^string. 
Endif 

If thare is not enough space in the tempjbuffer for this type attribute 10 

Allocate another tempjauffer and link it into the tenpjbuffer list 
Endif 

Calculate number of bytes needed to store bits. 

If there is not enough space in the target_buf fer for this ASN.1 data element 
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Error 
Endif 

If top fc of_stack Initial ready « no 

If 00t_type - REAL 

Assign -type attribute value to t«np_buffer. 
Else if DOl_type « LOMG^REAt 

Assign type attribute vilut to teapjauffer. 
Els* 

Error 
Endif 

If top_of_stsck rec_count « 0 /* for th« liaple-type array type »/ 

Sat init_*lreaoy * yes. 
Endif /* «lu this data • learnt um * part of a record V 

Endif 

Assign ASH.1 data element to target.buffer, 

recordjo_cdr() 

If re*tr1ctv*>_tYpe doe* not have a legal value 

Error 
Endif 

If la*t_iteai was string typo 

If thera is not enough space in tha tespjauffer to restart octetstring 
In type attribute* buffer 

AUocata another temp_buffer and link it into the tevp buffer Hat. 
Else 

Restart type attributes octetstring for IDs. 
Endif 

Set last_iteoi « not_string. 
Endif 

If there is not enough spsee in the teesibuffer for this type sttribute 10 
and the re*trietiv«_aMgr«ent type attribute 

Allocate another temp_buffer and link it into ths ttep buffer list 
Endif 

If there is not enough space in the tsrget.buffer for this ASN.1 data elesi 
Endif 

If init_aLreaoy ■ no 

If compression * PACXEO 

Assign type sttribute value to tespjxrffer. 
Else if compression a NONE 
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Assign type attribute value to temp^buf fer. 
EUa 

Error 
Endif 

Assign type attribute 10 to teespjxiffer. 

Increment top^of^stack rec_eount« 
Endif 

Assign restrict ive_align»ent type attribute to tempjajffer. 
Assign ASM.1 data element to targetjxrffer, 

. record jtnd_toj:dr{ ) , 

If initial read/ « no 

0 cerement top_of_staek rec_count. 

If top_of_stack ree.count ■ 0 /» sust do this check hart for "/ 
Set initial reedy » yes, /■ srrsy of records to work */ 

Endif 
Endif 

If there is not enough apace in the targetjxrff er for this ASM«1 dats element 

Error 
Endif 

Assign ASH.1 data element to target^buf far. 

\l3 string jtojcdr() 

If souree_ptr ■ KULL 

Error 
Endif 

If max^nua chara • 0 OR 

cur r_ length > oax_nun_ehars 

Error 
Endif 

If laet_i tern was string type 

If there is not enough space in the tamp_buf fer to restart octetstring 
in type attributes buffer 

Allocate another temp_buffer and link it into the tenp_buffer list. 
6ls« 

Restart type attributes octetstring for IDs* 
Endif 
Endif 

If there is not enough space in the tempjauffer for this type attribute 10 
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and mox_ncia__ch « rt 

AUocut another teapjbuffer and link ft fnto the teapjxrffer list 

Endff 

If there is not enough *pece in the tsrget_buf fer for this ASH.1 data ela 

Error 
Sndff 

if top_of_ttack Initial reedy « no 

Assign typo attributa 10 to teapjxiffer. 

End tmnpjxjffmr typa attrfbutas octatstrfng. 
Assign aam_nu«_chars typa attribute to temp_buffer. 

If top_of_atack rtc.cont « 0 /* f or tha staple- type array typa •/ 

Set init_alreaay * yws, 
Endff /* atsa this data element was a part of a record V 
Endff 

Assign ASH.1 data • tenant to target Jauffer. 
Sot I as t_ I tea « string. 

< ujnijojcdti) 
If source_ptr - HULL 

Endff 

If bft_length « 0 

Error 
Endff 

If t as t_f test was string typa 

If there is not enough spece fn tha teapjxrffer to raatart octatstrfng 
fn typa attrfbutas buffar 

Allocate another terap^buffer and link ft tnto tha test) buffar list- 
Else 

Rastart typa attrfbutas octatstrfng for 10s. 
Endff 

Set lastjtea) • not_string. 
Eneiif 

If thara fs not anough spaca fn the tarap_buffer for thfa typa attributa 10 

Ailocata another tc*p_buffer and link ft Into tha tesp buffar list 
Endff 

Calculate number of bytas needed to store bits. 

If there is not enough space fn the target J>uff ar for this ASM.1 data elan 
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Error 
Endif 

If top_pf_stack init^already * no 

5 

If ODL^Type - U_BYTE 

Assign type act rl but a value co teap Jsuffer. 
Else if OOL^type « UJHORTJNT 

Assign attribute value to t«np_buff«r. 
70 EUe if 0DL_type « UJMTEGER 

Assign type attribute valua to tenpjxjffer. 
Else if DDl w type « UJ.OMGJMT 

Assign typa attribute vatua to. tespjxrffer* 
Else 

75 Error 

Endif 

If top_of_«tack rec_eount ■ 0 /* f or the siople-type array type V 
Set Initial ready ■ yes* 
20 Endif /* else this data element uas a part of s record */ 

Endif 

Assign ASK.1 data element to target_buffer. 

25 
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Test Cases for Type Attribute Compaction 

These test cases show the type attribute compaction that would be p er fo rm ed for the data structures 
s specified. The asterisked ('*') items indicate the type attribute IDs that would actually go into the type 
attributes buffer: 

1. Testing: simple data type 
to Marshalling Calls Used: 

fnt * 

75 2. Testing: array of simple type 
Marshalling Calls Used: 



20 



•rrvy • 
fnt • 



fnt 
fnt 



orreyjend 



25 



3. Testing: record containing a simple type 



Marshalling Calls Used: 



30 



record * 
fnt • 
record end 



35 4. Testing: record containing two simple types 



Marshalling Calls Used: 



record • 
int * 
ehor * 

record end 



45 S. Testing: record containing an array of simple type 



Marshalling Calls Used: 
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TO 



75 



20 



25 



record * 
irrty * 
int * 
int 
frit 
■rray_«nd 
record end 



6, Testing: record containing an array of simple type followed by a different data element 
Marshalling Calls Used: 



record * 
•rrey * 
int * 
int 
int 
errey_end 
fnt * 
record end 



7. Testing: record containing arrays of simple type 
Marshalling Calls Used: 

30 record * 

errey * 
int * 

int 
int 

35 . array_end 

errey * 

int * 

int 
int 

40 arrey_cnd 
record_end 

8. Testing: array of records 

45 

Marshalling Calls Used: 
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15 



26 



35 



40 



array * 
racord * 

int • 
racord_and 
record 

int 
racord_and 
racord 

int 
racord^ and 
array_tnd 



9. Testing: nested records 
Marshalling Calls Used: 



racord 

20 Int 



racord * 
fnt • 
racord_and 
int * 



10. Testing: array of array of simple type, version 1 
30 Marshalling Calls Used: 



array * 
array ♦ 
fnt * 
int 
Int 
•rray_and 
•rray^end 



11. Testing: array of array of simple type, version 2 
Marshalling Calls Used: 



45 
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array * 
array * 

\i\z * 

Inc 

Int 
array.end 
array 

int 

fnt 

Int 
array_«nd 
array 

int 

lot 

inc 
array_«nd 
•rray„and 



12. Testing: array of array of array of ample type 
Marshalling Calls Used: 



array^and 
array^and 
array_«nd 



25 



30 



array * 
array * 
array * 

<nt * 
Int 
array_«nd 
array_«nd 
array 
array 
Int 
fnt 
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APPENDIX F 

Pseudocode 



Library Initialization 
/* Don* «t cosipile/llnk time: •/ 

Set pointers in language tables to point to Low- level unmershalling routines* 

Set pointer* in language table pointer (Itp) tible <ltp_table> 
to point to language tables* 

Main UnniarshaUing Routine 

r 

Heady to start procesaing next data aessage that cosies in. Call 
the sequence of code below for each new aessage that comes in. 

t*rget_ptr is passed in froa the caller and should already be 
pointing to the start of the target_buffer in which unmarshalled 
dat* e tenants will be deposited. 

The saws will be true of octets^avail. This will be passed in by 
25 the caller and will be initialized to the nuober of bytes in the 

target_buffer. 

V 
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bits_avail ■ 0. /* used in case unaarshalled eleaents take up only parts 
of bytes V 

Set data_buf _ptr to the start of the data buffer (set equal to source_ptr). 

UnswjrshaU the data buffer header in the source Jxrff er using a eethod that 
doesn»t use type attributes. Main concern here Is maintaining 
consistency in type and size of header data between machines, 
fteturn pointer to remainder of seuree_buffer (the start of the user data). 

Set source_ptr to the start of the user data <uso the pointer 
returned from above). 

Use language 10 from the source^buffer data buffer header as an offset 
into It potable. Set ltp_table_ptr to point to this location in 
ltp_table. 

Add type^ettr^start of feet to data_buf_ptr to obtain address of stsrt 
of type attributes area. Set type_attr_ptr to this address* 

Add type_attr_ length to type_attr_start and assign to end_of_type_attr_ptr. 
•nd_of_type_attr _ptr offers another way to check for end* of -processing 
(■ whole message has been unaarshalled). end_of_type_attr_ptr should 
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be pointing to the byte address AFTER the last type attribute byte. 

Assign erdj»f_user i data_ptr to type_attr_ptr. erd_of_usec_dataj>tr 
oiUrz stilt another wsy to check for end-of -processing (■ whole 
message hss been trwarmhslled). end_of_user_dataj)tr should 
be pointing to the byte address AFTER the last user data byte (which 
is the seme as the start of the type attributes). 

top_of_stack ■ NULL r etart with a fresh stack */ 

Push a "default* stack frame onto the stack, type.attribute field 

of the stack frame is "default-, mxtjtejtjncr field is set to 1. 
This default atack frame is used for processing data message* 
containing simple data types. 

openjsctetstring « false. /* flag used in checking type attr completion V 

Repeat f* do this loop once for each user data item V 

If open_octetetring « false /* start new octetstring V 
If type_attrj>tr pointa to octetstring type/length 

Hove type_ettr_ptr past octetstring type/length so that it 
points to the next type attribute to process. 

Elae 

Error 
Endif 

Else /* etill in the middle of an open octetstring V 

If type.attrjatr points to octetstring type/length 
Error 

Endif 
Endif 

/* at this point, type_attr_ptr should be pointing to the neat 
type attribute to process V 

open_octetstring » true. /* the header for the type attributes octetstring 

has been read; flag means octetstring closing 
trailer will eventually be expected to show 
up */ 

Verify that the type attribute ID is correctly peired with the user data 
ASM.1 tag type by looking up the type attribute in the ddl_asnl_table 
and retrieving the associated ASH.1 tag. 

If the user data tag ■ ddl_esn1_table tag /• match between user data 

and type attributes? V 

If the type attribute ID is an array/packed* array/record/packed- record 
If bits_avail o 0 /* align target_ptr to next byte boundary •/ 
target_ptr * target_ptr ♦ 1. 
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bits_avail * 0 
Endff 

If type attribute 10 is an array or pecked array 

Allocate • stack frame. 

If (Pascal/300) 

/* Sat top^of^staek values: */ 
2-byte_alfgn_ptr * Calculata 2* byte alts 
4-byte_align_j>tr ■ Calculata 4 -byte alignment* 
targat_ptr » 4-byte_aUgnjitr. /* most possible casa */ 

Endff 

/• else let element type set the ali gn me n t for the array V 

Set next_f tem_incr in the stack frame to 0. 

Increment type_attr_ptr by adding hardcoded 1 to it. 
Else 

If CPescal/300) 

Allocate a stack free*. 

/* Sat top_of_atack values: */ 

2-byte_alfgn jatr » Calculate 2 -byte alignment, 

4-byte_el ign_ptr « Calculate 4 -byte alignment. 

target ^ptr « 4-byte_align_ptr. /* moat possible esse */ 

Else If <Pescal/800) 

Allocate e stack fraaan 

Align to largest field or byte, whichever fa larger. 
Else If CC/300) 

If top_of_stack ■ default /* stack empty? */ 

Alignment ia 4 bytes. 
Else 

Alignment is Z bytes. 
Endff 

Allocate a stack frame. 
Else If CC/800) 

Allocate a stack frame* 

Align the target _ptr to a suitable starting location according 
to most_restrictive field in stack frame. 

Endif 

/* else for Fortran/300, Fortran/800 let low* level routine 
do the aligning */ 

Set next_ite»Jner field in the stack frame to 1. 
Increment type.attrjjtr by adding hardcoded Z to it. 
Endff 

Increment source^ptr to next data element. 

Else /* not a structured type, just a simple one... V 

/* need to feed size and alignment to the particular unmarshell 
routine; these are passed as globals to the routine; •/ 
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size ■ (*Cltp_tableCltp_tablejJtrJ Ctop_of^*t»ck*>p«cJced_op_notI)) 

C*type_attr_ptrJ Csizel ; 
alignment * (*<ltp_tabletltpjtable_ptr] ttop_of_st*cfc-*pacfced_or_r»tn) 
r*type_attrjstr] [alignment J ; 

If size or alignment are <■ 0 /* which they shouldn't be; •/ 

Warning /* means I an? tables are corrvpt V 

Uee appropo defaults. /* or incorrect. */ 

End if 

/* Call an ASH.1 low-level unmarshall routine specific to the 
OOt type; this routine, is pointed to by the OOL entry in the 
language table. 

Unlike the other data types , the cdr_to_string<) routine will 
reed the type attributes end- octetst ring. It will then reed the 
e*ut_nua_ehara type attribute. After reeding the end* octets tring, 
the routine acts open_octetstring to false. 

All routines increment source_ptr to the next date element 
only if successful; do not increment if not successful. 

•/ 

If ((result • ltp_tablej>tr->t*tack->pecked]Uj)tr-> 

lang_tableC*type_attr _ptr]->t«sirsh_rtnO) l« SpSuccesa) 

Error 
Endlf 

If top_of_stack next_ite«Jncr is 1 

Set type_ettr jjtr to type_attr_lastj»s. 
End if /* else current structured type is en array so don't anve 
type^attrjatr */ 

/* type_»ttr - last_po* is the furthest position in the type 
attribute buffer that type^attr^ptr has travelled* */ 

Endif 
Endlf 

If source _ptr < end_of jjser_data _ptr /* if any user data res* ins */ 

f* eoc processing : attempt to advance source^ptr before advancing 
type_attr_ptr */ 

While (source jstr octet * eoc) 00 /* may be many eoc ( s in a row */ 
Increment source _ptr to next data item* 
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/* need to Adjust alignment of 300 structured type? */ 
If CPescal/300) 

/* looking for th# on**/two-byte t true fur** V 

tf C<*iie_of ^truet * target_ptr - 4-byte_al I on _ptr) <« 2) 

/* one-byte case? V 

If (top_of_stecfc ■ record) AW) (sixe_of_struct * 1) AMO 

d-byte^tlionjatr o 4-byte_al f gn_ptr) /* see* location? V 
Byte* copy size_of_$truct number of bytes fro* 4*byte_altgn jJtr 

to 1-byte_elign_ptr location, 
target_ptr « terget_ptr - 1 

r two-byte ease? •/ 

Else If <2-byte_elignj3tr o 4-byte_align_ptr) 

0yte-copy aix«_of_»truct number of bytes froa k - byt c_« I \ gn^ptr 

to 2-byte_eUgnjjtr location, 
target_ptr « target^ptr - Z 

Endif 
Endff 
Endif 

If CC/fiOO) AMO (top_of_stack U a record) 

Align target _ptr so that next une» rebelled data eleannt 
starts on a aultiple of tost- restrictive type in record 
(need to check this sultipleness el lament 
business with Pascal). 

Endif 

If top_of_stack ■ default /* stack ewsaty too soon? V 

Error 
Endif 

If top_ef_stacfc ■ array - 

Set type_ettrjstr to type w attr_last _pos. 
Endif 

Pop top_of_steck 

If new top_of_ stack « default /* stack eapty? */ 

Break loop. 
Endif 

If new top_of_stack fs array 

Set type_attr_ptr to array_start jsos. 

/* if this top_of_atack array frmm was for an array of arrays 
or an array of records, type_attrj5tr aright have 
incremented far from it. Need to reset beck to handle 
next array/record within the array */ 
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Endif 
Endwhile; 
Endif 
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Until <top_of_stack » default) OR 

(aource^ptr « end_of,user_datej>tr) Oft 
Ctype^attr _ptr « end^of.type^attr _ptr); 

5 

/* check type* attribute completion depending on final state */• 

If epen_oetetstring ■ true /* final type attribute eoc was not read? */ 
If type^attr _ptr + Z «nd - of_tvpe - «ttrjitr 
*0 Warning 

Elae ff type_attrjatr is not an eoc 

warning 
Endif 
Elae 

? 5 if type_attr_ptr o end_of_type_attr^ptr 

warning 

Endif 
Endif 

20 f* Do some more checks to se« if processing was totally complete V 

If source _pcr o erd_of_user_datajstr /* some user data left */ 

Error /• unprocessed? V 

Else If top^of.stack o default /• did not elos* tost records/arrays? */ 

25 Error 
Endif 

/* reclaim stack apace V 
30 Freo (top_of_stack). 
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Primitive U nmarsliallmg Routines 

There are pointers in the Language Tables to these routines. During the unmaishalling process, a 
Language Table is accessed and the pointer to the specific primitive unmaishalling routine is used to 
invoke that routine. At that point, the actual process of unmaishalling takes place. The routine uses 
parameters from the Language Table itself to do the unmaishalling. These parameters include target 
data element size and alignment. After the conversion is performed, the primitive routine will deposit 
the convened data element in the target^buffer. 

These routines are as follows: 

cdr^tojieaderi ) 
unaarshelttng shell 

] cdrjiojnraiUr( ) 
j marshalling ***ell 

cdr_$oJbitJUld() 

/* Taaporaries for ueer_dsta_ptr # tsrget_ptr •/ 

«p_taap • uMr.data.jitr ♦ 1; (ASM typa field cheeked in thai I > 

tp_teap « tar^at_ptr; 

/* Ca lew lata alignment */ 

Update tp_teap according to all grant. 

F Check for avai labia space V 

If (ilia > spaca laft aftar appropriate alignment) 

HrrorC EJWjOUTCFBUFFER ) 
End if 

langth <. ASN.1 langth ftald Cut ba >-1, <-9), updating sp_ta*p 
unused <- ASH-1 contents octat ona (aust ba >*C. <«7), updating sp.tesp 
If Cftize < (( langth- 1)*8 - unusad)) 

ErrorC EM_T00B1G ) 
End if 

Loop on ASN.1 contants octets two to length 

If ((last (length) octet) and (unused o 0)) 

Transfer bits, updating sp_tenp f tp — tans> 

Else 

Transfer byte, updating sp_ts*p 4 tp_tanp 

Endif 
End loop 

Update octets_avail, bits_avail 
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Update user_data_ptr from ip_temp. 
Update target_ptr from tp_te»p. 
Return( success )♦ 

cdr_fojboot() 

/* Temporaries for us«r_dats_ptt\ target^ptr */ 

sp_temp • uaerjiatajstr ♦ 1; (ASM type field checked In shell) 

tpjeop » target_ptr; 

/* Calculate alignment */ 

Update tp_t«p according to alignment. 

/* Check for available space */ 

If (size > space left after appropriate alignment) 

ErrorC ERRjOUTOFBUFFER ) 
Endlf 

Check ASM. 1 length field (should be 1), updating sp.teop. 

If (ASM contents octet « 0) 

assign FALSE to target (bit or byte), updating sp.teop, tp.temp 
Else 

assign TRUE to tsrget (bit or byte), updating sp_temp # tp_t«np 
Endlf 

Update octets_aveil, bits_svail 
Update uscr_data jjtr from sp_temp. 
Update target jjtr from tp^temp. 
RetumC success ). 

cdrjtoj?har() 

J* Temporaries for user^date^ptr, target _ptr */ 

sp_tenp » uaer_data_ptr ♦ 1; (ASM type field checked In shell) 

tp_t«np » targetjtr; 

/* Calculate alignment */ 

Update tp_temp according to alignment. 

/* Check for available space */ 

If (size > space left after appropriate alignment) 

Error ( ERRJDUTOF SUFFER ) 
Endlf 

Check ASM.1 length field (should be 1) f updating sp.tonp. 
If (size < 8) 
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ErrorC ERftJTOOBlC ) 
Endif 

5 Tranefer thm byte (miM ASCII), updating *p_t«ap, tp_te*p. 

Update octets_avaf I, bits_avail 
Update u»er_data_ptr froa sp_teap. 
Update target_ptr fro* tp_te*p* 
70 RaturnC success >. 



cdrjoJnx{) 

J 5 /* Teeporaries for uaer_ciata_ptr # target_ptr */ 

«P_te*p « us*rdata_ptr ♦ 1; (ASM typa field checked in shall) 
tp H teep = target _ptr; 

/* Calculate eligrwent V 
20 Updata tp_tanp according to alignment. 

/* Check for available spaca •/ 

If (size > spaca laft after appropriate aligrwnt) 

ErrorC CRRJXJTOFBUFFER ) 
25 Endif 

length <- AS*\1 length field, legating sp.teep. 

If (size < ^length) 
30 ErrorC ERKJTOOBIG ) 

Endif 

Transfer tha bytes (sign extend ff necessary), updating sp^tewp, tp_teap„ 

Update octets^avstl, bits_av»il 
Updata user_data _ptr fro* spates?, 
Updata target_ptr fro* tp.teaeu 
*etum< success )„ 



35 



40 



cdrjio^opaque{ ) 



/* Temporaries for user_data _ptr, target j5tr •/ 

•P- t# »P * uaerjiata^ptr ♦ 1; (ASM typa field checked in shall) 

tp.teep « target _ptr; 

/» Calculate alignment V 

Update tp_te*p according to al lament. 

/* Check for available space V 

tf (size > space left after appropriate alignment) 
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Error< ERRJXJTOFBUFFER ) 
Endif 

length <- ASH.1 length field, updating «p_t«p. 

If (site < 3*-length> 

ErrorC ERRJTOOSIG ) 
Endif 

Transfer the byte* (octets), updating sp_tenp, tp_temp. 

Update octet*_ava i I f bits_avail 
Update user_data_ptr iron sp_tenp* 
Update target^ptr from tp^tewp, 
ReturnC success ). 



cdrjojreal() 

/* Temporaries for userjiatajJtr, target_ptr */ 

tp_tenp - user^datajstr + 1; (ASM type field checked in shell ) 

tp_tewp ■ targetjptr; 

/* Calculate alignment V 

Update tp^temp according to aligneent* 

/* Check for eve U able space */ 

If (site > space left after appropriate alignment) 

ErrorC ERRJXJTQFSUFFER ) 
Endif 

length <• length field, updating sp_tamp. 

If (size < fonaat_depend€nt_valua») 

ErrorC ERRJT0G81G ) 
Endif 

Transfer the real (involved translation), updating sp_tenp, tp_te«p. 

Update octet3_aveil, bits_avail 
Update uaerjdatajjtr from sp_tcmp* 
Update targetjstr from tp^tenp, 
ReturnC success )• 

cdr^tojstringO 

/* Temporaries for user_dataj>tr # targetjstr, type_attr_ptr •/ 
sp_tenp m user_data_ptr ♦ 1; (ASH type field checked in shell) 
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tp_t«np « target_ptr; 

•p^tamp » typa_attrj>tr «• 1; (sftell saw type attribute: string) 

/* proceaa type attribute information: aoe, ASH.1 integer (naxlen) V 

If C(ap_tenp* >)■*-»■ o eoc) 

UarningC?) 
Endif 

If C(ao - teop->)^ o type fnt) 

UarningC?) 
Endif 

aexlensixe » (ap_tenp->)*+ 

Transfer aultn (ap_temp«>) uaaxlenaize bytes}, updating ap_tmp 



/» Calculate alignment */ 

Update tp_te«p according to alignment* 

/* Cheek for avai labia «pae« V 

If (ai*a > apace left tfttr appropriate alignment) 

Error( ERR_OUTOFBUFFER ) 
Endif 

leneth <• ASH.1 length field, updating ep^tanp. 

If C length > naxlcn) 

Warning c truncation ) 
Endif 

If (size < oiaxlen) 

ErrorC ERR_TOOBIC ) 
Endif 

Transfer the byte* (iiium ASCII), updating *p_teop, tp_ttmp (by eaxlen ?) 
Null- terminate (C) or blank pad, if necessary. 

Update octets_avail 9 bt travail 
Update us«r_data_ptr from sp^temp. 
Update target^ptr from tp_tcnp. 
Update typa_attr_ptr from ap^temp. 
Sat open^octetstring to FALSE. 
ReturnC success ). 



cdrjtojuJnt() 

/* Temporaries for user^date^ptr, target _ptr */ 

*P_temp « uaer^datajatr * 1; (ASH type field checked in shell) 

tp^temp « target _ptr; 

/* Calculate alignment */ 
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10 



Update tp_tefflp according to eligmaent. 
/* Check for available spec* */ 

If Caiza > apace left after appropriate alignment) 

Error* ERR_ OUTOFBUf FER ) 
Endif 

lenoth <<• ASH.1 length field, updating sp_temp. 

If <aize < 8*length) 

Error< ERR_T008tG ) 
Endif 

75 Tranefer the byte* (zero extend if necessary), updating sp_teinp, tp_t«p. 

Update octeta_avail, bite_evail 
Update ueerjiata_ptr fro* sp_tewp. 
Update t ar get j5tr from tp_teep. 
20 Re turn C success ). 
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Test Cases for Main UnmarshaUing Routine 

The following is a listing of test cases used to desk check the data buffer parsing logic of the main 
routine pseudocode. 



For the user data specifications below, each item between commas re p r e s ents one ASN.l data 
element. 

For the type attributes specifications below, each item between commas represents one physical octet. 

1. Testing: simple data type 
Logical Format: 

char 

user data: char 

'type attributes: octetstring type, length, char ID, eoc type, length 

2. Testing: slight more internally complex simple type 
Logical Format: 

string 

user data: string 

type attributes: octetstring type, length, string ID, eoc type, length, int type, length, contents 
(max string size) 

3. Testing: array with simple type 
Logical Format: 

•rr«y C3J of ch«r 

user data: seq-of , char, char, char, eoc 
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type attributes: oaetstring type, length, array ID, char ID, eoc type, length 

4. Testing; array with slightly more internally complex simple type 
Logical Format: 

array CH of *trlng 

user data: seq-of , string, string, string, eoc 

type attributes: oaetstring type, length, array ID, string ID, eoc type, length, int type, length, • 
contents (max string size) 

5* Testing: record containing a simple type 
Logical Format: 

record 
char 

end 

user data: seq, char, eoc 

type attributes: octetstring type, length, record ID, restrictive type, char ID, eoc type, length 

6. Testing: record containing two simple types 
Logical Format: 

record 
boot 
char 

and 

user data: seq, boolean, char, eoc 

type attributes: octetstring type, length, record ID, restrictive type, boolean ID, char ID, eoc 
type, length 

7. Testing: record containing string type 
Logical Format: 
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record 
string 

end 

user data: seq, string, eoc 

type attributes: octetstring type, length, record ID, restrictive type, string ID, eoc type, length, int 
type, length, contents (max string size) 

Testing: record containing string type and simple type 
Logical Format: 

record 
string 
char 

end 

user data: seq, string, char, eoc 

type attributes: octetstring type, length, r ecor d ID, restrictive type, string ID, eoc type, length, int 
type, length, contents (max string size), octetstring type, length, char ID, eoc type, length 

Testing: r ecord containing an array of simple type 
Logical Format: 

record 

•rrey C3 of char 

end 

user data: seq, seq-of , char, char, eoc, eoc 

type attributes: octetstring type, length, r ecord ID, restrictive type, array ID, char ID, eoc type, 
length 

Testing: record containing an array of simple type followed by a different data element 
Logical Format: 

record 

•rrey C2J of boolean 
char 

end 
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user data: seq, seq-of, boolean, boolean, eoc, char, eoc 

type attributes: octetstring type, length, record ID, restrictive type, array ED, boolean ID, char 
ID, eoc type, length 

11. Testing: record containing an array of string type 
Logical Format: 



user data: seq, seq-of, string, string, eoc, eoc 

type attributes: octetstring type, length, record ID, restrictive type, array ID, string ID, eoc type, 
length, int type, length, contents 

12. Testing: record containing an array of string type followed by a different data element 
Logical Format: 

record 

array (23 of string 
char 

and 

user data: seq, seq-of, string, string, eoc, char, eoc 

type attributes: octetstring type, length, record ID, restrictive type, array ID, string ID, eoc type, 
length, int type, length, contents, . octetstring type, length, char ID, eoc type, length 

13. Testing: array of records 
Logical Format: 

array C23 of record 
char 
boolean 

end 

user data: seq-of, seq, char, boolean, eoc, seq, char, boolean, eoc, eoc 

type attributes: octetstring type, length, array ID, record ID, restrictive type, char ID, boolean 
ID, eoc type, length 
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14. Testing: ne d records 
Logical Format: 

5 

record 
char 
record 
Char 

and 

10 char 
•nd 
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user data: seq, char, seq, char, eoc, char, eoc 

type attributes: octetscring type, length, record ID, restrictive type, char ID, record ID, restrictive 
type, char ID, char ID, eoc type, length 



15. Testing: array of packed array of simple type 
20 Logical Format: 

array C31 of paekad array (23 of char 

25 user data: seq-of, seq-of, char, char, eoc, seq-of, char, char, eoc, seq-of, char, char, eoc, eoc 

type attributes: octetstxing type, length, array ID, packed array ID, char ID, eoc type, length 

16. Testing: packed array of array of simple type 
Logical Format: 

packed array p] of array C23 of char 

user data: seq-of, seq-of, char, char, eoc, seq-of, char, char, eoc, seq-of, char, char, eoc, eoc 
type attributes: octetstring type, length, packed array ID, array ID, char ID, eoc type, length 

17. Testing: array of array of string type 
Logical Format: 

array £3] of array 03 of string 

user data: seq-of, seq-of, string, string, eoc, seq-of, string, string, eoc, seq-of, string, string, eoc, 
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ccx: 

type attributes: octetstring type, length, array ID, array ID, string ID, eoc type, length, int type, 
length, contents (max string size) 

18. Testing: array of array of record type 
Logical Format: 

array Dl of ■rr«y C23 of record 

char 

and 

user data: seq-of, seq-of, scq, char, eoc, seq, char, eoc, eoc, seq-of, seq, char, eoc, seq, char, 
eoc, eoc, seq-of, seq, int, eoc, seq, int, eoc, eoc, eoc 

type attributes: octetstring type, length, array ID, array ID, rec o rd ID, restrictive type, char ID, 
eoc type, length 

19. Testing: record containing an array of records of simple type 
Logical Format: 

record 

array CZ3 of racord 
char 
and 

and 

user data: seq, seq-of, seq, char, eoc, seq, char, eoc, eoc, eoc 

type attributes: octetstring type, length, record ID, restrictive type, array ID, record ID, 
restrictive type, char ID, eoc type, length 



Claims 

1. A system for integrating user software application programs (402) operating on a network (LAN), 
comprising: 

application adapting means (404) operating on at least one node (400) of said network (LAN) for 
providing said user software application programs (402) with communicative access to said network 
(LAN); 

message management means (406) at at least one node (400) of said network (LAN) for managing 
data transfer requests between said user software application programs (402) operating on nodes (400) 
and other software application programs (402) connected to said network (LAN); 

means (416, 418) for establishing node to node communications between a source node (400) 
having a source user software application program (402) operating thereon from which a data transfer 
request has originated and a destination node (400) having a destination user software application 
program (402) operating thereon to which data is to be transferred; and 

data manipulating means (412) at said nodes (400) for manipulating message data from said source 
user software application program (402) into a common data representation for transmission to said 
destination user software application program (402), said message data from said source user 
application program (402) being manipulated when at least one of the data types, data formats and data 
representations of said source and destination user software application programs (402) do not 
correspond to each other. 
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2. A system as in claim 1, further comprising means (418) at said nodes (400) for manipulating message 
data in said common data representation received from said network (LAN) into the data types, data 
formats and data representations of said nodes (400) when said destination user software application 
program (402) operates on said nodes (400). 

5 

3. A system as in claim 2, wherein said data manipulation means (412) manipulates message data from 
said source user software application program (402) into said common data representation when said 
source and destination user software application programs (402) are written in different computer 
programming languages. 

10 

4. A system as in claim 3, wherein said common data representation is independent of the architecture of 
the nodes (400) and computer programming languages used on said network (LAN). 

5. A system as in claim 1 , further comprising means (FIG. 5) for forming node-specific data manipulation 
rs means (528) at each node (400) for manipulating data from said source user software application 

program (402) into a common data representation for transmission, and for manipulating data received 
in said common data representation into data compatible with said destination user software application 
(402), said data manipulation forming means comprising: 

file means (502) for storing a high level description of user software application programs (402) and 
20 nodes (400) operating on said network (LAN), the characteristics of data at each source and destination 
user software application program (402), and the manipulations necessary to convert data from source 
to destination characteristics; 

validation module means (504) for generating, as source code on a node (400) designated as an 
administration node (NODE 1), configuration files (510), based on said high level description; 
25 configuration table compiling means (506) and data manipulation compiling means (508) for 

generating, as source code on said administration node (NODE 1), manipulation files (512), based on 
said high level description; 

data manipulation module builder means (520) for copying said manipulation files (512) and 
compiling, on each node (400) designated as a compilation node (NODE 2), said manipulation files . 
30 (512) to form node-specific data manipulation modules (528); and 

start up module means (516) for copying said configuration files (510), for loading said configura- 
tion files (510) in memory and for starting up said data manipulation files (512). 

6. A method of forming a data manipulation module (528) for integrating user software application 
35 programs (402) operating on a network (LAN) so as to allow messages to be transmitted from a source 

user software application program (402) of a first data type to a destination user application program 

(402) of a second data type, comprising the steps of: 

(a) storing (502) as configuration source code (510) a high-level description of user software 
application programs (402) and nodes (400) operating on said network (LAN); 
40 (b) storing (508) as manipulation source code (512) the characteristics of data for source and 

destination user software application program (402) and the manipulations necessary to convert from 
data having the characteristics of data for a source user software application program (402) to data 
having the characteristics of data for a destination user software application program (402); 

(c) compiling, at a compilation node (NODE 2), for each node type in said network (LAN), said 
45 configuration source code (510) and said manipulation source code (512) so as to form node-specific 

data manipulation modules (528) at each compilation node (NODE 2); and 

(d) distributing said node-specific data manipulation modules (528) to each corresponding node 
(NODES 3-6) in distributed processing network. 

50 7. A method as in Claim 6, wherein said compilation site is a node on said network and wherein said 
steps (a)-(d) are conducted during startup of said nodes (400) on said network (LAN), whereby said 
node-specific data manipulation modules (528) are used during run time of said network (LAN) to 
convert messages from said first data type to said second data type to complete transmission of said 
message from said source user software application program (402) to said destination user software 

55 application program (402). 

8. A method as in claim 7, comprising the further step of validating (504) said configuration source code 
(510) prior to said startup step. 
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9. A method of transmitting message data from a first user application program (402) in a first 
programming language operating on a first node (CPU1) supporting a first data format to a second user 
application program (402) in a second programming language operating on a second node (CPU2) 
supporting a second data format comprising the steps Of: 

generating a request from said first user application program (402) that said message data be sent 
to said second user application program (402); 

determining whether a manipulation needs to be performed to send said message data from said 
first user application program (402) to said second user application program (402) so that said second 
user application program (402) can understand said message data; 

if a manipulation needs to be performed, converting said message data to a common data 
representation independent of said first and second programming languages and said first and second 
data formats; 

transmitting said message data from said first node (CPU1) to said second node (CPU2); 

receiving said message data from said first node (CPU1) at said second node (CPU2); 

determining whether a manipulation has been performed on said message data; and 

if a manipulation has been performed on said message data, converting said message data from 
said common data representation thereof to said second programming language with said second data 
format. 

10. A method as in claim 9, wherein said first and second user application programs (402) operate on the 
same node and hence only require programming language manipulations. 
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